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OBJECT-ORIENTED FRAMEWORK results when an object in one process is allowed to access an 

MECHANISM EOR PROVIDING object in another process. Ad istrihuted object environment, 

PERSISTENT STORAGE as used herein, means any hardware and software configu- 
ration and/or combination lhat allows an object in a first 

HELD OF THE INVENTION 5 process to access an object in a second process. Examples of 

The present invention relates in general to the data known distributed object systems include: 1) a first process 

processing field. More specifically, the present invention and a P rocess rcsidin S on lhe same computer; 2) a 

relates to the field of object-oriented framework mecha- flfSt P rocess and a ^ co ^ processes residing on different 

n l sms computer workstations in a local area network (LAN); and 

to 3) a first process and a second process residing on computers 

BACKGROUND OF THE INVENTION in geographically remote locations that are interconnected 

. . . c rnWAr , 4 , c using a wide area network (WAN). As technology 

The development of the LDVAC computer system of & . . . , . . \ / ... , ~; 

, nAO . p .. | . . . f ( . K , progresses, other distributed object systems will, no doubt, 

1948 is often cited as the beginning of the computer era. T 5 , . » .u . ■ :• i 

. , t. . .. , , . be developed, and the present invention expressly encom- 

Smce that lime computers have become indispensable in n . rr.-u.iu-. . u *u 

c . . * . , • - 15 passes all types of distributed object systems, whether now 

many fields ot human endeavor including engineering ; r . . . iL f t J ' 

. . J , . i • r ?■ . known or developed in the future, 

design, machine and process control, and information stor- r 

age and access. In the early days of computers, companies Objects are typically made persistent by storing their state 

such as banks, industry, and lhe government would purchase data m a local dala slore * In man y ^ own computer systems, 

a single computer which satisfied their needs, but by the the P rocess of makin S an ob J ecl Persistent is known as 

early 1950's many companies had multiple computers and 20 "extemahzation". Extemahzation is the means or protocol 

the need to move data from one computer to another became used ,n object-oriented programming for transferring data 

apparent. At this time computer networks began being out of an object. In essence the "state data" that defines the 

developed to allow computers to work together. attributes of an object are "externalized", or written out of 

„ 4 , ui r ■ u *u « the object, into a different format that is easily stored in the 

Computer networks are capable of performing jobs that „ , , ' 1WI _ ... , . 4t _ 

, . it p i n l 4 25 local data store. When the object is needed again, the 

no single computer could perform and they allow low cost . • . i • , 

, , r . 4* \ * externalized state data is internalized into an object, creating 

personal computer systems to connect to larger systems to * . . • ■ • . 

c * j ju* ui * 4 ii 4 c an exact copy of the object as it previously existed, 

perform tasks lhat such low cost systems could not perform vy J y J 

alone. In order for computer systems to cooperate in a Objects that are located on different computer systems 

network to perform some complex job, software must be may have different attributes that allow the object to be 

developed which efficiently delegates parts of the chore or stored in the local data store. For example, one computer 

tasks to different computers in the network. One of the system may store data in a fiat file (such as a POSIX file) in 

recent advances in the field of software development has a standard directory structure, and objects on this computer 

been the emergence of object-oriented programming tech- system will be configured to store their state data in the 

no | Q gy appropriate file format. A different computer system may 

TTie 'goal of using object-oriented programming is to store data in a relational data base (RDB), and objects on this 

create small, reusable sectioas of program code known as computer system will be configured to store their slate data 

objects that can be quickly and easily combined and re-used in ,he RDB tormat - 

to create new programs. This is similar to the idea of using Known persistent storage systems limit the types of data 

the same set of building blocks again and again to create 40 that can be stored persistently. For example, a particular 

many different structures. The modular and re-usable aspects persistent storage system may only support RDB or POSIX 

of objects typically speeds development of new programs, formats. Consequently, users may have access to data that 

thereby reducing the costs associated with the development cannot be stored persistently simply because the persistent 

cycle. In addition, by creating and re-using a group of storage system in use does not support storing data of that 

well-tested objects, a more stable, uniform, and consistent 45 particular format. This problem becomes more acute as more 

approach to developing new computer programs can be computer systems with different persistent storage systems 

achieved. become interconnected in a distributed object environment. 

Although object-oriented programming offers significant As the need for persistent storage of wide varieties of data 
improvements over other programming types, program formats grows, the need for better mechanisms for storing 
development still requires significant amounts of time and 50 persistent data becomes more apparent. Without a mecha- 
effort, especially if no preexisting objects are available as a nism that can be readily customized and extended to provide 
starting point. Consequently, one approach has been to new persistent storage systems, the computer industry will 
provide a program developer with a set of pre-defined, never fully realize the potential and power of sharing data in 
interconnected classes that create a set of objects. Such distributed object systems, 
pre-defined classes and libraries are typically called object 55 ciivimadv nr mr iwvcrvninM 
frameworks. Frameworks essentially provide a prefabri- SUMMARY OF FHE INVEN1ION 
cated structure for a working program by defining certain As discussed in the Background section, there is a serious 
classes, class relationships, and methods that a programmer need in the industry for user-extensible persistent storage 
may easily use by appropriate subclassing to generate a new systems. According to the present invention, an object- 
object-oriented program. 60 oriented framework mechanism for persistent storage envi- 

An object in an object-oriented computer program typi- ronments systems provides an infrastructure that embodies 
cally has attributes defined by state data that determine how the steps necessary for a framework consumer (ie., user) to 
the object will behave. If an object is transient, it is created define persistent storage for any type of data not supported 
within a process, and terminates when the process ends. If an in the persistent storage system by extending the framework 
object is persistent, however, mechanisms are put in place to 65 to fit a particular persistent storage environment. Certain 
allow the object to survive the process that creates it so it can core functions are provided by the framework, which inter- 
be accessed by other processes. A distributed object system act with extensible functions. A user may thus define exten- 
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sible functions that allow the framework to support many 
different types of persistent data stored in datastores capable 
of storing the persistent data. 

The framework mechanism of the present invention was 
designed and constructed using object-oriented technology. 
Those who are unfamiliar with object-oriented technology, 
or with object-oriented framework mechanisms, should read 
the object-oriented overview section of the Description of 
the Preferred Embodiments section. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. I is a category diagram of an example framework 
mechanism; 

FIGS. 2 through 6 are class diagrams for the example 
framework mechanism of FIG. 1; 

FIG. 7 is an object diagram for the example framework 
mechanism of FIGS. 1 through 6; 

FIG. 8 is a block diagram of the computer system used in 
the preferred embodiment; 

FIG. 9 is a flow diagram showing steps in accordance with 
the preferred embodiment to perform core functions of the 
framework mechanism; 

FIG. 10 is a category diagram of a framework mechanism 
constructed in accordance with the teachings of the preferred 
embodiment; 

FIGS. 11-14 are class diagrams of a framework mecha- 
nism constructed in accordance with the teachings of the 
preferred embodiment; 

FIG. 15 is a class diagram showing the extension of the 
framework to implement three specific persistent storage 
environments; 

FIG. 16 is a class diagram showing the extension points 
for defining an ODBC persistent container; and 

FIG. 17 is an object diagram of the ODBC persistent 
storage environment represented in FIG. 16. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Overview — Object-Oriented Technology 

As discussed in the Summary section, the present inven- 
tion was developed using Object-oriented (00) framework 
technology. Individuals skilled in the art of 00 framework 
technology may wish to proceed to the Detailed Description 
section of this specification. However, those individuals who 
are new to framework technology, or new to 00 technology 
in general, should read this overview section in order to best 
understand the benefits and advantages of the present inven- 
tion. 

Object-oriented Technology v. Procedural 
Technology 

Though the present invention relates to a particular OO 
technology (ie., 00 framework technology), the reader must 
first understand that, in general, 00 technology is signifi- 
cantly different than conventional, process-based technol- 
ogy (often called procedural technology). While both tech- 
nologies can be used to solve the same problem, the ultimate 
solutions to the problem are always quite different. This 
difference stems from the fact that the design focus of 
procedural technology is wholly different than that of 00 
technology. The focus of process-based design is on the 
overall process that solves the problem; whereas, the focus 
of 00 design is on how the problem can be broken down 
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into a set of autonomous entities that can work together to 
provide a solution. The autonomous entities of 00 technol- 
ogy are called objects. Said another way, 00 technology is 
significantly different from procedural technology because 
5 problems are broken down into sets of cooperating objects 
instead of into hierarchies of nested computer programs or 
procedures. 

The Term Framework 

10 There has been an evolution of terms and phrases which 
have particular meaning to those skilled in the art of OO 
design. However, the reader should note that one of loosest 
definitions in the 00 art is the definition of the word 
framework. The word framework means different things to 

1S different people. Therefore, when comparing the character- 
istics of two supposed framework mechanisms, the reader 
should take care to ensure that the comparison is indeed 
"apples to apples." As will become more clear in the 
forthcoming paragraphs, the term framework is used in this 

20 specification to describe an OO mechanism that has been 
designed to have core function and extensible function. The 
core function is that part of the framework mechanism that 
is not subject to modification by the framework purchaser. 
The extensible function, on the other hand, is that part of the 

25 framework mechanism that has been explicitly designed to 
be customized and extended by the framework purchaser. 

00 Framework Mechanisms 

30 While in general terms an 00 framework mechanism can 
be properly characterized as an OO solution, there is nev- 
ertheless a fundamental difference between a framework 
mechanism and a basic OO solution. The difference is that 
framework mechanisms are designed in a way that permits 

35 and promotes customization and extension of certain aspects 
of the solution. In other words, framework mechanisms 
amount to more than just a solution to the problem. The 
mechanisms provide a living solution that can be customized 
and extended to address individualized requirements that 

40 change over time. Of course, the customization/extension 
quality of framework mechanisms is extremely valuable to 
purchasers (referred to herein as framework consumers or 
users) because the cost of customizing or extending a 
framework is much less than the cost of a replacing or 

45 reworking an existing solution. 

Therefore, when framework designers set out to solve a 
particular problem, they do more than merely design indi- 
vidual objects and how those objects interrelate. They also 
design the core function of the framework (i.e., that part of 

50 the framework that is not to be subject to potential customi- 
zation and extension by the framework consumer) and the 
extensible function of the framework (i.e., that part of the 
framework that is to be subject to potential customization 
and extension). In the end, the ultimate worth of a frame- 

55 work mechanism rests not only on the quality of the object 
design, but also on the design choices involving which 
aspects of the framework represent core function and which 
aspects represent extensible function. 

ZAF — An Illustrative Framework Mechanism 

60 

While those skilled in the art appreciate that framework 
design is necessarily an intertwined and iterative process, 
example design choices for a simplistic framework mecha- 
nism arc set forth in the paragraphs that follow. It should be 
65 understood, though, that this is only an example framework 
that is being used in this specificalion to illustrate and best 
explain framework mechanisms such that the reader can 
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understand and appreciate the benclit.s ;u J advanta^s nf the 
present invention. 

Framework designers determine what objects are needed 
for a framework mechanism by selecting objects from what 
is called the problem domain. The problem domain is an 
abstract view of the specific problem at hand. The example 
problem domain chosen for this illustrative framework 
mechanism is that of zoo administration. The specific prob- 
lem is that of designing a mechanism that assists zoo keepers 
in the care and feeding of zoo animals. In our example of a 
Zoo Administration Framework (ZAF), an 00 framework 
designer would look to the zoological problem domain and 
decide that any ZAF would of necessity involve a mecha- 
nism that represented the relationship between zoo keepers 
and animals (i.e., to represent how zoo keepers care for 
animals). The framework designer would also likely recog- 
nize that zoo animals usually live in cages, pens, tanks, and 
other sorts of containment units. Therefore, our framework 
designer would start with the idea that the framework would 
have to involve mechanisms that represented all of these 
fundamental entities and relationships. 

How ZAF is Designed 

To begin the design process, our framework designer 
would likely begin with what is called a category diagram. 
Category diagrams are used to describe high level frame- 
work mechanisms, and how those mechanisms relate to one 
another. FIG. 1 is a category diagram for the example 
framework ZAF. The notation used in FIG. 1, and that used 
in the other figures of this specification, is explained in detail 
in the Notation section at the end of this specification (pages 
22-27). Each mechanism in a category diagram represents 
groupings of objects that perform a particular function. For 
the purposes of illustration, assume that our framework 
designer decides that ZAF should be made up of four high 
level mechanisms: a zoo administration mechanism, a zoo 
keeper mechanism, an animal mechanism, and a contain- 
ment unit mechanism. 

As shown in FIG. 1, the zoo administration mechanism 
has been designed to use the zoo keeper mechanism to 
administer the zoo. The zoo administration mechanism is 
therefore said to have a using relationship with the zoo 
keeper mechanism. (Again, please refer to the notation 
section of this specification for an explanation of this 
relationship and the other notation used in this 
specification.) 

As discussed, the zoo administration mechanism has been 
designed to have responsibility for overall control of ZAF. 
Accordingly, the zoo administration mechanism is respon- 
sible for scheduling the operation of the zoo keeper mecha- 
nism. Note also that our framework designer designed the 
zoo administration mechanism to be a core function of ZAF, 
which means that it has been designed such that it will not 
be subject to potential customization and extension. The C 
in the category box denotes this fact. Please note further that 
the uses relationship between the zoo admin istrat ion mecha- 
nism and the zoo keeper mechanism has also been designed 
such that it is not available for ultimate customization by the 
framework consumer. 

The zoo keeper mechanism has been designed to be 
generally responsible for the care and feeding of the zoo 
animals. Accordingly, it uses the animal and containment 
unit mechanisms to perform its tasks. However, unlike the 
design of the zoo administration mechanism, our framework 
designer has designed the zoo keeper mechanism to be 
extensible function, which again means that the zoo keeper 
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mechanism has been designed to be available for modifica- 
tion and/or extension by the framework consumer to address 
future care and feeding requirements. This fact is denoted by 
the E in the zoo keeper mechanism category box. 

5 Our framework designer has designed the animal mecha- 
nism to represent the animal side of the interaction between 
zoo animals and zoo keepers. Since the animal population in 
the zoo is something that changes on a regular basis, the 
animal mechanism has similarly been designed as an exten- 

10 sible function. The containment unit mechanism interacts 
with the zoo keeper mechanism by representing individual 
containment units such as pens, tanks, and cages. Like the 
animal mechanism, the containment unit mechanism has 
been designed as an extensible function such that it can 

15 handle future customization and extension requirements. 
Please note here, however, that even though the zoo keeper, 
zoo animal, and containment unit mechanisms have all been 
designed as extensible function, the relationships between 
the mechanisms have been designed to be a core function of 

0Q ZAF. In other words, even though it is desirable to give 
ZAF's consumers flexibility relative to the zoo keeper, zoo 
animal, and containment unit mechanisms, it is not desirable 
to allow ZAF's consumers to change how these mechanisms 
relate to one another. 

^ 5 Our framework designer would next design the classes 
and relationships that make up the mechanisms shown on 
FIG. 1. A class is a definition of a set of like objects. As such, 
a class can be thought of as an abstraction of the objects or 
as a definition of a type of object. From the view of a 

3 q computer system, a single object represents an encapsulated 
set of data and the operation or a group of operations that are 
performed by a computer system upon that data. In fact, in 
a secure computer system, the only access to the information 
controlled by an object is via the object itself. This is why 

35 the information contained in an object is said to be encap- 
sulated by the object. 

Each class definition comprises data definitions that 
define the information controlled by the object and operation 
definitioas that define the operation or operations performed 

40 by objects on the data that each object controls. In other 
words, a class definition defines how an object acts and 
reacts to other objects by defining an operation or set of 
operations that Is/are performed on the defined data. (Please 
note that operations are sometimes called methods, method 

45 programs, and/or member functions.) When taken together, 
the defined operation^) and data are said to be the behavior 
of the object. In essence, then, a class definition defines the 
behavior of its member object or objects. 

FIG. 2 is an 00 class diagram that shows the fundamental 

50 classes that our framework designer has designed for ZAF. 
Each class representation includes its relationship to the 
mechanisms shown on FIG. 1. For example, we can see that 
the zoo keepers class is denoted as being from Zoo Keeper 
Mechanism. The fundamental classes of ZAF include: the 

55 zoo administrator class, which is part of the zoo adminis- 
tration mechanism; the zoo keeper registry class, which Is 
also part of the zoo administration mechanism; the animal 
registry class, which is part of the zoo keeper mechanism; 
the zoo keepers class, which is also part of the zoo keeper 

60 mechanism; the containment unit registry class, which is 
also part of the zoo keeper mechanism; the animals class, 
which is part of the animal mechanism; and the containment 
unit class, which is part of the containment unit mechanism. 
Please note again that the relationships between the 

65 classes have been designed as core function of ZAF such 
that they are not available for ultimate modification by 
ZAF's consumers. 
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The zoo administrator class is the definition of the objeel consumers to customize and extend the zoo keepers, 

that is respoasible for the overall control of ZAF. Again, 00 animals, and containment unit classes, these classes have 

classes only define the objects that interact to provide a been designed as extensible function. However, changing 

solution to the problem. However, it is by exploring the the behavior of the animal and containment unit registry 

characteristics of the class definitions that we are able to 5 classes would disrupt the basic operation of ZAR Therefore, 

understand how the objects of the framework mechanism th ese classes have been designed to be core functions of 

have been designed to provide a living solution that can be ZAh 

customized and/or extended to address future requirements. While the classes and categories within ZAF have been 

p« j • . i u u « a~ ■ ~a u»™ „ described as either core ftnetions or extensible functions, it 

The zoo administrator class has been designed to have a . . , „ r A . „ . 

i „;*u t u~ -™ i™™..- rw r.™„ io is important to note that the term "core function as used 

uses relationship with the zoo keeper registry. Our trame- 1U . . . ,, , A • , ,l * . L r 

■ I- u i a *u ^ ™ herein broadly relates to requirements that cause the frame- 
work designer has designed the zoo administrator and zoo . . • .L 1 * J II* 

, ^ , . * % r 7AC .^^.^ rtlir work to operate m the desired manner. In simple terms, core 

registry classes to be a core function or ZAF because our . *• * , . L c *u * 

, - . i -j i ,l . 7ac> i 1 1 « « u~ functions of a framework are the functions that any program 

designer has decided that ZAF s consumers should not be , , r . lt - _ - * r 

, . ,- r . , *■ u- . .u * u that uses the framework will perform. Ihe requirements of 

allowed to modify the behavior of objects that are members . , . * . . . t M t - 

Ci , . , c i • * u- u u is core functions may be imposed by the structure of the 

of these class definitions. The zoo keeper registry, which has 15 e . . . ■ i 

wha. is called a contains by reference relationship with the ^mework (e.g., by des.gna .ng certain classes as core 

zoo keeper class, is simply a class that defines an object that ^ nc ", ons ) or ™y * lm P° se <? b V funcUonal «^"?™«s 

; . f „ , i • . i r«„i„ Ik-™* that dictate how a framework consumer may utilize the 

is a container for all zoo keeper objects. Accordingly, the zoo r t , . . _, t J . . , 

, . t , ■ ' i r , n i-i t „ framework. ITius, core functions include not only the classes 

keeper registry includes a definition for a list_zoo_ . . .. . ... , ■ t . . . 

i /\ a mi u a u a i.,*-, iWr™™»; n n 20 an d cl ass relationships that are designated as core, but may 

keepersO operation. As will be described later, this operation 2U , ... A ... , iL ' . , , , j* 

■li c -r i ■ > r , /■ * * also include extensible classes that must be implemented in 

is responsible for providing a list of zoo keeper objects to r , L r i , t 101 

tL i ■ . .L . * u r * particular ways for the framework to function properly. Said 

other objects that request such a list. F . 7 ... , ... _ . . t . y t p / e t , 

J n . , another way, while extensible function is that part of the 

FIG. 3 shows a lower level view of the zoo administrator framework that fc desigDed to be customized by the frame- 
class. Since objects of type zoo administrator have respon- WOfk consumer> the nature and exlent of the customization 
sibility for overall control of ZAF, the zoo administrator ^ ned by the requ irements of the framework's core 
class has been designed to include operations that perform faction ( ie ., the overall framework function imposed by the 
tasks oriented towards zoo administration. The class defi- structure and functional requirements of the framework), 
nition includes the following five operations: 5_minute_ For examp , C) the an i ma ls class has been designed as exten- 
timer(), add_ammal(), add_containment_unit(), add_ ^ sib , e function of ZAF ^ that ZAF can be customized to 
zoo_keeperO, and start_zoo m admin(). accommodate different types of animals. However, the abil- 

r ITie start_zoo__adminO operation is responsible for start- j ly to customize the extensible animals class does not imply 

ing ZAR That is, a user or system administrator will interact that the nature of the customization can violate the basic 

with the start_zoo_adminO operation to begin administra- structure imposed by the core function of ZAF (e.g., by 

tion of a zoo via ZAF, Once started, our framework designer 35 customizing the animal class to the extent that it can no 

has designed the start__zoo_admin() operation to initiate the longer be reasonably said to represent a type of animal). 

5_minute__timer() operation. Every five minutes, the FIG. 4 is a class diagram of the zoo keeper class. 

5_minute_timer() operation instructs the zoo keeper However, before describing the details of FIG. 4, it is 

objects to go out and check on the animals. The add/delete_ worthwhile to point out that the class definitions shown on 

zoo_keeper operation is responsible for interacting with 4Q FIG 4 are ran k ed j n a very simple ordering called a class 

users of ZAF to define additional zoo keepers (ie., additional hierarchy. A class, like the zoo keeper class, that represents 

zoo keeper classes), to add additional zoo keepers (i.e., zoo the most generalized/abstract class in a class hierarchy is 

keeper objects), and to remove zoo keeper classes and/or re f err ed to as the base class of the hierarchy. The ordering of 

objects. As will become clear in the forthcoming paragraphs, classes in a class hierarchy goes from most general to least 

each zoo keeper object is responsible for performing a 45 genera i (f x ^ f rom general to specific). Less general classes 

particular zoo task. Therefore, it is natural that a user of ZAF ( e g ^ me feeder c i ass ) are ^id to inherit characteristics from 

might well want to add a zoo keeper definition and object to the more general class or classes (i.e., the zoo keeper class 

handle an additional zoo task or to remove a definition or in lhis case j ^ such5 dass definitions feeder, veterinarian, 

object that is no longer needed. As will be seen, this and temperature controller are said to be subclasses of the 

flexibility is provided by designing the zoo keeper mecha- $Q zo0 keeper dass inheritance mechanisms will be explored 

nism as an extensible function. m more deta ;i j n me discussion associated with FIG. 5. 

Like the add/delete_zoo_Jceeper operation, the add/ As shown on FIG. 4, the zoo keeper class definition 

delete_animal() operation is responsible for interacting with contains a single operation definition, the check_animals() 

users to define additional zoo animal classes and objects and operation definition. The reader should also note that the zoo 

to remove classes and objects that are no longer needed. ss keepers class definition is marked as being an abstract class. 

Again, it is quite natural for a zoo to need to add and remove Abstract classes are not designed to have objects created as 

animals. The add/delete_containment_unil() operation is their members, but are instead used to define a common 

responsible for the definition of new containment unit interface/protocol for their subclasses. A class is said to be 

classes and objects and for removal of classes and/or objects an abstract class when at least one of its operation definitions 

that are no longer necessary. Again, our framework designer 60 ^ a pure virtual operation definition. Pure virtual operation 

has designed ZAF in a way that provides this flexibility by definitions are designed for the sole purpose of defining a 

designing the animal and containment unit mechanisms as common interface for subclass definition of that operation, 

extensible functions. In other words, the design of the actual behavior (i.e., the 

Referring back to FIG. 2, the zoo keepers class definition data and operations) is left to the subclasses themselves. In 

has a uses relationship with the animal registry, animals, 65 the case of the zoo keeper class definition, the feeder, 

containment unit registry, and containment units classes. veterinarian, and temperature controller subclasses define 

Since the value of ZAF' is enhanced by allowing ZAF's specific implementations of the pure virtual check__ 
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animals() operation definition that is contained in the zoo lion. Default operations are used to provide generic function 

keeper class. An operation is marked as a pure virtual when to subclasses. The subclasses can simply use the default 

it is set equal to 0. operations or they can customize or extend the default 

It is important to note, though, that the common interface operations by redefinition. Redefinition of a default opera- 

of a pure virtual operation definition must be honored by all 5 tion is called overriding the default operation, 

subclasses such that requesting objects (called client objects) Mammals is a subclass of class animals, and as such, 

can use subclass member objects (called server objects) mammals inherits all of the characteristics of class animals, 

without needing to know the particular subclass of the server Please note that class mammals is also designed as an 

object. For example, whenever the object defined by the zoo abstract class, which again means that it has not been 

administrator class needs a particular action performed, it 10 designed to have objects created as its members, but has 

interacts with a zoo keeper object. Because the interface to instead been designed to provide a common interface for its 

these objects was defined in abstract, base class zoo keeper subclasses. Subclass mammal is further subclassed into 

and preserved in the subclass definitions for the check__ classes carnivore and herbivore. 

animals() operation, the zoo administrator object need not since definition of the feed() operation has been left up to 

have special knowledge about the subclasses of any of the ^ tne subclasses, subclasses carnivore and herbivore each have 

server objects. This has the effect of decoupling the need for meu - own definition of the feed() operation. Again, this is a 

the action (ie., on the part of the zoo administrator object) gooc i design choice because meat eating carnivores are 

from the way in which the action is carried out (i e., by one going t0 have different needs than their plant eating coun- 

of the objects of the zoo keepers subclasses). Designs (like terparts. 

the ZAF design) that take advantage of the characteristics of 20 ^ c is a da(a definilion for the range of lem . 

abstract classes are said to be polymorphic. peratures that coincides with that of the specific animal's 

Polymorphism is extremely important to 00 framework natural habitat and the get„temp„range() operation defini- 

design because it allows the way in which something is done uon ^ designed to retrieve the temp_range for a specific 

(called the implementation) to be changed or extended arnma i an d return it to a requesting client object. Subclass 

without effecting the mechanisms that depend on the fact the reptiles contains its own data definition for temp_range and 

action is actually performed. In other words, client objects j ts OW n definition for the get_temp__range() operation. ZAF 

need only understand that certain objects perform certain has been designed this way to point out that data definitions 

functions, not how those functions are actually carried out. can be overridden just like operation definitions. Since many 

This is one way in which a properly designed framework can reptiles live in desert conditions, where nights can be very 

be readily customized and extended to satisfy future require- co id and days very hot, the default temp_range definition 

ments. has been overridden in the reptiles class to include time and 

As previously discussed, our framework designer has temperature information (not explicitly shown on FIG. 5). 

designed ZAF such that zoo keeper objects interact with This is another good design choice because it allows ZAF to 

animal and containment unit objects to perform their tasks. 35 treat reptile containment units differently than other con- 

FIG. 5 is a class diagram for the class hierarchy of the tainment units by allowing temperature adjustments to be 

abstract class animal. Since the animals class definition is made based on the time of day as well as on the current 

responsible for representing the characteristics and behavior temperature of the containment unit itself, 

of zoo animals, the framework designer has designed piG. 6 is a class diagram showing a lower level view of 

abstract class animal in a way that reflects this responsibility. 4Q tne containment unit class. The containment unit class 

As shown, the example animal class definition includes data contains virtual operation definition adjust_tempO- The 

definitions feed_freq, location, and temp„range and opera- adjust_temp definition defines both the interface and 

tion definitions get_Jemp„range(), feed(), needs_food(), mechanism used to actually adjust the temperature in the 

needs__vet„visit(), and vet_visit(). containment units of the zoo (i.e., via heating and cooling 

For the purposes of this framework overview, it is not 4S mechanisms which are not shown), 
necessary to explore each definition in detail. However, the 

temp_range data definition and the get_temp_range() and How*the A ZAR Objects Interact 

feedO operation definitions are good examples of well Beyond designing the objects that make up the solution to 

thought out framework design choices. the specific problem, our framework designer must also 

The feed() operation definition is designed to perform the 50 design how the individual objects interrelate. In other words, 

actual feeding of the animals (i.e., through specific feeding the objects must interrelate in way that takes advantage of 

apparatus which is not shown). The feed() operation is a pure the manner in which they were designed. As discussed, the 

virtual operation. Again, this means that the design of the way in which the defined operations of an object operate on 

class is such that the actual mechanism that performs the the data defined for the object is called the object's behavior, 

needed function has been left to be defined by the sub- 55 While objects may be characterized as autonomous entities, 

classes. Requiring subclass definition is a good design it is still very important that each object exhibit a consistent 

choice in cases like this where objects that are created as behavior when interrelating with other objects. Consistent 

members of the subclasses have particularized needs. In behavior is important because objects depend upon the 

ZAF, for example, each type of animal is likely to have need consistent behavior of other objects so that they themselves 

for a particularized feeding apparatus, which not only makes 60 can exhibit consistent behavior. In fact, consistent behavior 

definition of a generic feedQ operation difficult, but value- is so important that an object's behavior is often referred to 

less. as the contract the object has with the other objects. When 

By way of comparison, the framework designer has an object does not exhibit a consistent behavior, it is said to 

explicitly designed the get_Jemp_range() operation such have violated its contract with the other objects, 

that it is not a pure virtual operation definition. This means 65 When an operation of one object needs access to the data 

that get_teinp__rangeQ has been generically defined as a controlled by a second object, it is considered to be a client 

default operation. As such, it is considered a virtual opera- of the second object. To access the data controlled by the 
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second object, one of the operations of the client will call or The adjusi_iempO opt; n vi of each containment unit 

invoke one of the operations of the second object to gain then completes the control tio* by proceeding lo adjust the 

access to the data controlled by that object. One of the temperature in a way thai Is appropriate lor the animals 

operations of the called object (i.e., a server operation in this contained in each containment unit. (That is, the temperature 

case) is then executed to access and/or manipulate the data 5 ^ adjusted based on time and temperature for Snake Pit 3 

controlled by the called object. and based on lime a[one for y on Cage 7 ) nc rcader shouid 

PIG. 7 is an object diagram showing how the example note tna t the relationship between the check_animals() 

objects of ZAF interact to assist zoo personnel in operating operation and the adjust tempO operations is polymorphic, 

the zoo. A detailed analysis of the interaction of all of the In other words> tne c heck_animalsO operation of object 

ZAF objects is unnecessary for the purposes of this over- 1Q Tm 6qqs nQ{ {n specialized knowledge about how each 

view However, the reader should review the following ^. |em ^ } {on forms fts ^ ^ check 
simple control flow to obtain a rudimentary understanding of J {mM) ™ ^ mefe , ' had l0 abide b the interface and 

how objects interact to solve problems. ... * y ,. r t , a aa .u . *. • . .u 

J ... , . . c call the adiust__tempO operations. After that, it is up to the 

As mentioned, an object is created to be a member or a . ,. . , , , . A * *u • ♦ i 

™ mbuiiuuvu, i* vjvvi * individual adjust tempO operations to carry our their tasks 

particular class. Therefore, Zelda the Zoo Administrator . , J — rv r J 

[object 706] is an object that is a member (actually the only 15 10 me proper manner 

member) of the zoo administrator class. As such, object At this point, it is again worthwhile to point out that the 

Zelda is responsible for overall control of ZAF. All of the ZAF mechanism is an extremely simplistic framework 

zoo keeper objects have registered with the Zoo Keeper mechanism that has been presented here to help novice 

Register object [object 700]. Therefore, object Zelda obtains readers understand some basic framework concepts so as to 

a list of the current zoo keepers by calling the lLst_zoo_ 20 best appreciate the benefits and advantages of the present 

keepers() operation [step I] of the Zoo Keeper Register invention. These benefits and advantages will become more 

object. The Zoo Keeper Register object has been created as clear upon reference to the following Detailed Description, 
a member of the zoo keeper register class. For the purposes 

of illustration, assume that this occurs every five minutes as Notation 

part of Zelda's 5_minute„timer() operation. The Zoo is 

Keeper Register object then responds with the zoo keepers 11ierc LS > as ve, > n0 uniformly accepted notation tor 

list [step 2]. The list of zoo keepers includes Tina the communicating object-oriented programming ideas. The 

Temperature Checker [object 714], Vince the Vet. [object notation used in this specification is very similar to that 

740], and Fred the Animal Feeder [object 752]. Each zoo known in the programming industry as Booch notation, after 

keeper has been created as a member of the zoo keepers 30 Grady Booch. Mr. Booch is the author of Object-Oriented 

class. In particular, objects Tina the Temp. Checker, Vince Analvsis and Design With Applications, 2nd ed. (1994), 

the Vet., and Fred the Feeder are respectively members of available from The Benjamin/Cummings Publishing 

the temperature controller, veterinarian, and feeder sub- Company, Inc. Use of Booch notation concepts within this 

classes. specification should not be taken to imply any connection 

Once the list of current zoo keepers has been returned to 35 between the inventors and/or the assignee of this patent 

object Zelda, object Zelda instructs each zoo keeper in the application and Mr. Booch or Mr. Booch's employer. The 

list to check the animals by calling the check animals() notational system used by Mr. Booch is more fully explained 

operation of each zoo keeper object [only the call to Tina the at Chapter 5, pp. 171-228 of the aforementioned book. The 

Temp. Checker is shown— step 3]. Please note that object notational system used herein will be explained generally 

Zelda did not need to understand the types of zoo keepers 40 below - 0lher notational conventions used herein will be 

that were in the zoo keeper list, the number of zoo keeper explained as needed. 

objects in the list, or the specialized characteristics of any A system that is modeled by an object-oriented frame- 
one zoo keeper object. Object Zelda uses the same interface work can be represented at a high level of abstraction by a 
(i.e., the check_animals() operation) to communicate with diagram called a top-level class diagram. FIG. 1 of the 
each zoo keeper object. It is then up to the individual zoo 45 drawings is an example of a top-level class diagram con- 
keeper objects to perform the task for which they have been taining boxes that represent abstractions of the modeled 
created. Each zoo keeper object performs its assigned task- system. The boxes-are -arranged in a hierarchy such that 
through use of its own check_animals() operation. For boxes representing abstractions close to the physical corn- 
example, object Tina's check_animals() operation retrieves ponents of the system are at the lower levels of the diagram 
a list of current animals from the animal registry object by 50 a nd boxes representing more abstract, functional compo- 
calling the list__animals() operation [step 4] and then a list nents are closer to the top of the diagram. In FIG. 1, the 
of containment units from the containment unit register boxes are labeled as "mechanisms" to denote that the 
object by calling the list__cont_units() operation [step 6]. abstractions comprise means for implementing modeled 
Upon examining the animal list, object Tina's check__ system components. The boxes (mechanisms) can be 
animals() operation determines that there are only two 55 thought of as categories comprising groups of similar classes 
animals currently registered in the zoo, Sam the Snake defined according to object-oriented programming concepts, 
[object 728] and Simba the Lion [object 7L8]. FIG. 1 represents a zoo administration model and therefore 
Object Tina's check_animals() operation then calls the the lower hierarchy boxes include a box called Animal 
get temp__range() operations to get temperature ranges from Mechanism, which represents animals within the zoo model, 
objects Sam and Simba [steps 8 and 10]. Once the tempera- 60 and a box called Containment Unit Mechanism, which 
lure ranges have been returned, the check__animals() opera- represents animal pens and cages. At the highest level of 
lion of object Tina determines which containment units FIG. 1, the box called Zoo Administration represents a 
house the respective animals (ie., Simba and Sam) and then functional abstraction that encompasses a variety of admin- 
calls the adjust_temp0 operation of the appropriate con- istrative tasks that are performed by personnel, 
tainment unit (i e., Lion Cage 7 in the case of object Simba 65 The boxes in a top-level class diagram represent the 
and Snake Pit 3 in the case of object Sam) to adjust the system abstractions that provide the system behavior. The 
temperature of the containment units [steps 12 and 13]. system abstractions include classes and objects. Details of 
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ihc sybi r i classes arc provided in a class diagram icu is languages, such as Small Talk, support the concept of a 

used to show the class categories and to indicate the- rtla- metaclass. Such relationships are denoted by a shaded line 

tionships and responsibilities of the classes. A class is with an arrowhead pointing from an instance of a metaclass 

represented by an irregularly shaped, dashed-line icon com- to the general metaclass. 

monly referred to a cloud. FIG. 2, for example, shows 5 Classes can be parameterized, which denotes a family of 

several classes represented as clouds. Each class is identified classes whose structure and behavior are defined indepen- 

by a name that is unique to the associated class category and Gently of its formal class parameters. A parameterized class 

also indicates the relationship of each class to one of the ^ represented by a cloud-shaped class icon with a rectan- 

mechanisms illustrated in FIG. i. Within a class icon, the gu i ar box placed over a portion of the cloud. The parameter 

class name is listed above attribute names, operation names 10 \[ S { ^ named within the rectangular box. An instantiated 

followed by parentheses, and constraints that are enclosed c i ass includes a parameter box, called an adornment, in 

within brackets. FIG. 3 illustrates the class Zoo Adminis- contrast to a dashed line box for a general class. The 

trator in greater detail. FIG. 3 indicates that the Zoo Admin- instantiation relationship between a parameterized class and 

istrator class includes multiple operations, including ones j ts instantiated class is represented as a dashed line pointing 

called u 5_minute_timer0", "add_animalQ", and "add__ is (0 the parameterized class. Typically, an instantiated class 

containment_unit()". Words in the operation names (and requires a "using" relationship to another concrete class for 

class attribute names) are separated by an underscore for use as an actual parameter. 

easier reading. An example of a class attribute listing is p r0 p er ties of classes can be represented by class adom- 
shown by the attributes called "feed freq and temp_ mcnts ^ afC cndoscd wi , hin the dass c|oud icQn , n 
range m the class Animals illustrated in MG. 5. 20 particuIarj an abstract class is denoled by an upper case 
Connecting lines between mechanisms (FIG. 1) and block "A" within a triangle that is placed within a cloud. An 
classes (FIG. 2) indicate the nature of the relationships abstract class is a class for which no instances may be 
between such respective abstractions. Thus, connections created. That is, it is a class of classes. Other class adorn- 
between the boxes in FIG. 1 represent relationships between m enls are functions of the 00 implementation language. For 
the various mechanisms. A straight connecting line, for 25 example, the C++ language permits special class qualifica- 
example, represents a simple association relationship indi- t i ons tn at win be given special adornments. Astatic class is 
eating shared information. A "using" relationship is a refine- represented by an upper case block "S" within an adornment 
ment of a simple association whereby one abstraction that is triangle, a fiend class is denoted by an upper case block "F" 
referred to as a server or supplier provides services to w i tn j n an adornment triangle, and a virtual class is repre- 
another abstraction that is referred to as a client. Such a 30 sentecl by an upper case block « V " within an adornment 
relationship is indicated by an open circle at one end of a triangle. 

simple association line, the open circle end designating the [n addhion tQ defming c]asseSj a designer of an objec( _ 

client that 'uses the associated server. oriented programming system must define objects (see page 

Another refinement of a simple association between two 135 G f Booch). Objects are represented as solid line clouds 

classes Is a type referred to as an inheritance relationship. within which is placed the object name located above a list 

Inheritance is a relationship among classes in which one 0 f object attributes. An object is a tangible entity that 

class shares the structure and/or behavior associated with exhibits a well defined behavior. An object is intended to 

one or more other classes. An inheritance association is also represent some part of a real system that is being represented 

referred to as a "is a" relationship. Thus, given two classes by the object-oriented program. An object is characterized 

A and B, the class A has an inheritance relationship with the by a slale , a behavior, and an identity. An object can be 

class B if A is an example of a B; A is said to be a subclass thought of as an instance of a class. The behavior of an 

of B and B is said to be a superclass or parent of A. That is, object is an indication of how the object acts and reacts in 

A "is a" B. An inheritance relationship is denoted with a terrns Q f i ts sta te changes and its message-passing actions, 

connecting line that includes an arrowhead at one end to Qb - amJ theif interrelationships are represented in 

indicate a subclass that derives its characteristics from a objec t diagrams that comprise object icons having links that 

parent class at the other end of the line. indicate s y nchromzatio*between>objects : Links are sequen- 

Another refinement of class relationships is called an ti a Uy numbered to indicate the flow of operations. The 

aggregation relationship, which denotes an association existence of a link between two objects indicates an asso- 

between a whole and its parts or attribute classes. In 50 c i a ti on between their corresponding classes and denotes a 

notation, an aggregation relationship is indicated between a pat h of communication between them. Thus, a link between 

whole class and an attribute class connected with an asso- t wo objects indicates that one object may send messages to 

ciation line by a solid circle at the whole class end, with an another. The direction of message transfer is indicated by 

attribute class at the other end. adorning a simple connecting line with an arrowhead that 

Another relationship specified by a class diagram is an 55 points from an object that invokes an operation, referred to 

instantiation relationship. An instantiation relationship rep- as the client, to the object that provides the operation, 

resents an instance of a class such as a particular implemen- referred to as the supplier. Such a representation of a simple 

tation of a class as supported by a programming language. synchronization relationship denotes the simplest form of 

For example, a class called "animal" can have multiple message-passing. Such an association can indicate, for 

instantiations comprising lions, tigers and bears. An instan- 60 example, the invocation of an operation. Operation param- 

tiation of a class is represented by a dashed association line cters can be indicated adjacent the linking line, 

with an arrowhead pointing from an instance of a class to the Some objects may be active, meaning that they embody 

general class. their own thread of control. That is, such objects arc not 

Finally, a class relationship referred to as a metaclass simply sequential. Active objects may have a variety of 

denotes a relationship in which a class itself is treated as an 65 concurrency characteristics. If an object has multiple threads 

object that can be manipulated. That is, a metaclass is a class of control, then synchronization must be specified. Message 

whose instances are themselves classes. Some computer synchronization can be synchronous, meaning that the client 
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w ill wait until the supplier accepts the message. Synchro- mechanisms that allow the programs of computer system 
nous synchronization is indicated with an "X" with an 800 to behave as if they only have access to a large, single 
arrowhead. Synchronization can encompass balking storage entity (referred to herein as computer system 
message-passing, meaning that the client will abandon the memory) instead of access to multiple, smaller storage 
message if the supplier cannot immediately service the 5 entities such as main memory 820 and DASD device 855. 
message. Balking is indicated with an arrowhead turned Therefore, while application programs 822, objects 824, and 
back on itself. Synchronization can encompass a time-out operating system 828 are shown to reside in main memory 
synchronization, meaning that the client will abandon the 820, those skilled in the art will recognize that these pro- 
message if the supplier cannot service the message within a grams are not necessarily all completely contained in main 
specified amount of time. Time-out synchronization is indi- 10 memory 820 at the same lime. Note that the term "memory" 
cated with a clock face representation adjacent a linking is used herein to generically refer to the entire virtual 
arrowhead. Finally, synchronization can encompass an asyn- memory of computer system 800. 

chronous message, meaning that the client sends an event to Operating system 828 Is a suitable multitasking operating 
a supplier for processing, the supplier queues the message, system sucn ^ AIX; however, those skilled in the art will 
and the client then proceeds without waiting for the supplier. 15 appreciate that the spirit and scope of the present invention 
Those skilled in the art will appreciate that asynchronous ^ not limited to any one operating system. Operating system 
message synchronization is analogous to interrupt handling. 828 preferably supports an object-oriented programming 
Asynchronous message synchronization is indicated with a environment such as that provided, for example, by the C++ 
half arrowhead. programming language. One or more application programs 
It bears mention that the Booch notation includes inter- 20 822 provide a programming environment for computer 
action diagrams that trace the execution of objects and system 800, and . include a persistent storage framework 
classes. Interaction diagrams are essentially restructured mechanism 870, which is preferably an object-oriented 
object diagrams. That is, interaction diagrams convey the framework mechanism. Framework mechanism 870 con- 
same information from that conveyed by object diagrams, tains instructions capable of being executed on CPU 810 and 
but simply present the same information in a different 25 may exist anywhere in the virtual memory space of corn- 
format. The present specification makes use of object dia- puter 800. 

grams for the ZAF example and for the description of the Although computer system 800 is shown to contain only 

invention, and those skilled in the art will recognize that a s j ng [ c ma i n CPU and a single system bus, those skilled in 

interaction diagrams are equivalent and also will understand tne art w jn appreciate that the present invention may be 

how to convert from one to the other without further 30 practiced using a computer system that has multiple CPUs 

explanation. and/or multiple buses, whether contained in a single unit or 

In FIG. 7, for example, the object called Zelda 706 obtains distributed across a distributed processing computer system, 

a list of current zoo keepers by calling an operation called In addition, the interfaces that are used in the preferred 

List Zoo Keepers from the object called Zoo Keeper Reg- embodiment each include separate, fully programmed 

ister. The second processing step is represented in FIG. 7 by 35 microprocessors that are used to off-load compute -intensive 

the Zoo Keeper Register object responding to the operation processing from CPU 810. However, those skilled in the art 

call by passing a message to the Zelda object that comprises will appreciate that the present invention applies equally to 

the zoo keeper list. The zoo keeper objects include members computer systems that simply use I/O adapters to perform 

of the Zoo Keepers class called Tina, Vince, and Fred. The similar functions. 

third step indicated in the object diagram is for the object 40 Terminal interface 840 is used to directly connect one or 
Zelda to pass a message to each of the zoo keepers instruct- more terminals 865 to computer system 800. These termi- 
ing them to check the animals by calling the respective na i s 865, which may be non-intelligent or fully program- 
Check Animals operation of each zoo keeper object. ma bl e workstations, are used to allow system administrators 

45 and users to communicate with computer system 800. 

Network interface 850 is used to connect other computer 
FIG. 8 shows a block diagram of a computer system 800 systems and/or workstations (e.g., 875 and 885 in FIC. 8) to 
in accordance with the present invention. The computer computer system 800 in networked fashion. The present 
system of the preferred embodiment is a computer system invention applies equally no matter how computer system 
such as an AIX platform. However, those skilled in the art 50 800 may be connected to other computer systems and/or 
will appreciate that the mechanisms and apparatus of the workstations, regardless of whether the connection to the 
present invention apply equally to any computer system, network is made using present-day analog and/or digital 
regardless of whether the computer system is a complicated techniques or via some networking mechanism of the future, 
multi-user computing apparatus or a single user workstation. It is also important to point out that the presence of network 
As shown in the exploded view of FIG. 8, computer system 55 interface 850 within computer system 800 means that com- 
800 comprises main or central processing unit (CPU) 810 puter system 800 may engage in cooperative processing with 
connected to main memory 820, mass storage interface 830, one or more other computer systems or workstations. Of 
terminal interface 840, and network interface 850. These course, this in turn means that the programs shown in main 
system components are interconnected through the use of a memory 820 need not necessarily all reside on computer 
system bus 860. Mass storage interface 830 is used to 60 system 800. For example, one or more application programs 
connect mass storage devices (such as DASD device 855) to 822 may reside on another system and engage in cooperative 
computer system 800. One specific type of DASD device is processing with one or more programs that reside on com- 
a floppy disk drive, which may store data to and read data puter system 800. This cooperative processing could be 
from a floppy diskette 895. accomplished through use of one of the well known client- 
Main memory 820 contains application programs 822, 65 server mechanisms such as remote procedure call (RPC). 
objects 824, data 826, and an operating system 828. Com- At this point, it is important to note that while the present 
puter system 800 utilizes well known virtual addressing invention has been (and will continue to be) described in the 
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conicxt of a fully functional computer system, those skilled in the PersistentConlaincr class (see FIG. 16) that delegates 

in the art will appreciate that the mechanisms of the present a portion of the getEntity() function to the extensible por- 

invention are capable of being distributed as a program lions that define a particular persistent storage environment, 

product in a variety of forms, and that the present invention This delegation will be discussed in more detail below in the 

applies equally regardless of the particular type of signal 5 description of the ODBC system defined in FIG. 16. In short, 

bearing media used to actually carry out the distribution. the doGetEntityQ method retrieves state data from the 

Examples of signal bearing media include: recordable type persistent container and uses the stale data to create the 

media such as floppy disk (e.g., 895 of FIG. 8) and CD desired object. 

ROMs, and transmission type media such as digital and Note that a particular persistent storage environment may 

analog communication links. 10 not use some of the steps in method 900. These steps are 

defined by the framework, and allow a user of the frame - 

Persistent Storage Framework Mechanism of the wor k to pick and choose (he specific steps and their order 

Present Invention needed to provide a variety of different persistent storage 

The persistent storage framework mechanism disclosed environments. Note also that while the core function of 

herein provides an architecture for providing different per- 35 ^wor^ 870 is described with reference to FIG. 9 for the 

sistent storage systems on a computer system. Extending the g*Entity() method one skilled in the art will recognize that 

framework to accommodate a specific type of persistent oth f methods ' such 35 "cateEntityO or deleteEntityO, will 

storage system defines a "persistent storage environment/ 1 P erform sl ™ laT ste P s Mlh mmor vanallon s to accomplish 

For example, extending the framework to define an ODBC the desired fancllon - 

persistent datastore for objects creates a persistent storage 20 ^ fact that the preferred embodiment of the framework 

environment that is tailored to the storage requirements of an IS object-oriented allows the user of the framework to easily 

ODBC system. define the needed functions by subclassing from the classes 

n j- i* i u cm -a.- defined within the framework using known object-oriented 

By providing framework mechanism 870 within com- A , * _ ' 

* . onA * j a • * * * * programming environments, such as C++. The preferred 

puter system 800 to define persistent storage systems, a - c r ° t b c ' . . 

•r • t f r ,, ... , i_ 25 embodiment of the present invention is an object-oriented 

uniform interface for all persistent storage systems may be ... c % «n.-i i «- * i • 

, , . r, i i_ ■ ota i nr persistent storage framework. While many different designs 

developed. Framework mechanism 870 may replace all of r . ... ' . . * c 

4 , r . t . t i t t . and implementations are possible, one suitable example of 

the proprietary persistent storage systems that are currently *" 4 , ... c i • i i 

* ui • j i t-u * i u . / an object-oriented persistent storage framework is disclosed 

incompatible in modem distributed object environments. . , J , ... . , . , & , 

~, . , , • / c e i c * below to illustrate the broad concepts of the present mven- 

Tnis would allow a common user intertace tor defining 3Q r r 

virtually any type of persistent storage system. This common 

user interface would greatly ease the burden of program- Class Definitions 

ming and maintaining persistent storage systems. Thus, one FIG. 10 is a category diagram of the persistent storage 

of the primary benefits of the framework disclosed herein is framework mechanism 870 in accordance with the preferred 

the capability to define new persistent storage systems using 35 embodiment. Only a single category Containers is defined 

a simple, easy to use user interface defined by the frame- that represents a collection of object-oriented programming 

wor ^' (OOP) classes that encapsulate data attributes and behaviors 

Referring to FIG. 9, an example of persistent storage (or methods). Objects iastantiated as members of these 
framework 870 in accordance with the preferred embodi- classes are stored in the main memory 820 of computer 
ment performs steps that comprise a method 900 for han- 40 system 800. All classes shown in FIGS. 11-16 are members 
dling requests to access persistent objects. For the purpose of the Container category. The container category is an 
of illustrating the core functions of framework 870, method extensible category (as indicated by the "E" label), meaning 
900 is directed to a specific method getEntity() that is that users may extend many of the classes in this category by 
defined by PersistentContainer. When getEntityO is called, defining and implementing classes that are subclasses of 
the parameters Handle and AccessMode are passed with the 45 framework-defined classes. These classes may be 
call. The Handle parameter identifies the entity, and the implemented, for example, in a computer system operating 
AccessMode parameter specifies how to access the entity. environment that supports the C++ programming language. 
For a getEntityO method, the first step is to check the cache FIG. 11 is a top level class diagram of the classes used to 
to determine whether the requested entity is in the cache implement persistent storage framework 870. Persistent- 
(step 905). If the entity is in the cache (step 910=YES), the 50 Container is an extensible abstract class that allows a 
entity is retrieved from cache (step 915), and the entity (i.e., framework consumer to define a new type of persistent 
object) is returned (step 960). If, however, the entity is not container through appropriate subclassing. PersistentCon- 
in the cache (step 910=NO), the container configuration tainer provides the core container implementation required 
must be determined (step 920). Next, an empty object for the by all concrete container subclasses. The PersistentCon- 
requested entity is instantiated (step 925). A transaction ID S5 tainer class provides all the necessary interfaces required by 
is then determined for the transaction (step 930), along with the factory for managing Ihe lifecycle of persistent objects, 
the applicable resource (step 935). Next, the security of the An object that desires to perform operations on object in a 
entity is checked (step 940) to assure the caller object may PersistentContainer must do so through the methods pro- 
access the entity, and the lock state is checked (step 945) to vided in PersistentContainer. For example, if a factory object 
both assure the object is not already locked and to lock the 60 needs to create, update, or delete anything stored in a 
object through the end of the transaction. Next, the object is PersistentContainer, the methods on PersistentContainer are 
fluffed up (step 950), stored in cache (step 955), and returned invoked to accomplish these functioas, PersistentContainer 
to the caller (step 960). also includes all the necessary methods required for a 

The manner of fluffing up the object (step 950) depends on persistent object stored in the PersistentContainer to partici- 

the type of persistent container that is defined, and the 65 pate in transactions. This includes methods for getting 

extensible portions of framework 870 determine how the access to, dropping access to, and persisting the entity to 

fluffing up is performed. A method doGetEntily() is defined persistent storage. 
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PersistentConiaincr defines a number of other methods as a part of. Note that specifying a ContainerClassConfig 
well One of these methods is createO, which is a constructor object automatically specifies a corresponding Container- 
method thai creates a persistent container. Containers are StoreConfig object as well because the ContainerClassCon- 
instantiated dynamically by an object (such as a factory) as f lg class has a "has" relationship with the ContainerStore- 
needed. A factory object first retrieves the string to object 5 Config class. 

mapping of the container ID to the ContainerConfig object n ^ c . , , , , ,, . . . . 

; r & ^ . . n . /\ ResourceConne is an abstract extensible class that is 

ana passes the ContainerConfig object to the createf) con- . ■ i u .i. ^ c i r» ^ c 

structor method for the PersLntContainer. In addition, contained b / lhe ContamerConfig class. ResourceConfig 

PersistentContainer defines methods createEntity(), deflnes configuration data for a particular type of transac- 

deleteEntityn, and getEntity() that create, delete, and lft tional resour^ For example ResourceConfig defines the 

retrieve, respectively, an entity (i e., persistent object) in the 10 corresponding Resource class that is used by a container. For 

PersistentContainer. All requests for object creation, an XA transaction, the ResourceConfig object contains the 

deletion, and updating are routed through the appropriate xa„open and close string information. 
PersistentContainer. CacheManager is an abstract extensible class that defines 

The PersistentContainer class has a "has" relationship 15 how ob J ects are cached in a particular persistent storage 
with each of the CacheManager class, the ContainerConfig environment. In other words, a CacheManager object man- 
class, and the LockManager class, indicating that each ages the in-memory objects that are owned by a correspond- 
PersistentContainer object will have an associated Cache- in S persistent container. CacheManager defines methods 
Manager object, ContainerConfig object, and LockManager getCachedEntityQ, putCachedEntityQ, and 
object. In addition, PersistentContainer has a "using" rela- 20 re move Cached En t it y() that retrieve, store, and delete, 
tionship with the AccessMode class, the SecurityManager respectively, cached entities in the cache. CacheManager has 
class, the Resource class, the ResourccManager class, and a " has " relationship with CachedEntitylnstance and Handle, 
the Transact ionManager class CachedEntitylnstance class is a core class that is used 

The AccessMode class is a core class that defines allow- t0 define an ^-memory copy of objects stored in a particular 

able ways to access an entity. The LockManager class is 25 Patent container Cache^dEntitylnstance is a wrapper class 

responsible for providing concurrency control of objects °f an 'n-memory object, llie Handle class is an extensible 

stored in persistent containers defined by framework 870. class used b * CacheManager to identity objects stored in a 

LockManager has a "has" relationship with the Lock class persistent container. 

and with the AccessMode class, indicating that a lock CachedEntitylnstance has a "has" relationship with the 

manager will have one or more locks and an AccessMode 30 ClassConfig class and the ContainerClassConfig class, 

that dictate how the objects are managed. The Persistent- Furthermore, the Resource class has a "has" relationship 

Container class provides the sole interfaces for accessing Wlth the CachedEntitylnstance class, indicating that a 

and locking a persistent object. LockManager defines the resource object may have a corresponding cached entity 

methods lockEntity() and unlockEntityO to perform locking instance object. The ClassConfig class is an abstract exten- 

of entities (ie., persistent objects) according to the access 35 sible class that defines configuration data corresponding to 

mode provided as a parameter to the method calls. This class names. ClassConfig maps a class ID to a fully qualified 

assures that data written to a PersistentContainer is the class name > and includes methods to determine the class 

correct data, reconciling any differences between stored data name S iven the class ID and vice versa * The mapping is 

and cached data. unique and is used to show class names to a framework 

The SecurityManager class performs all security func- 4 o consumer rather than class IDs - 
tions for the persistent containers defined by framework 870, ContainerClassConfig is an abstract extensible class that 

such as task and object-level security. PersistentContainer defines configuration data for classes within a container. It is 

provides methods that interface with methods on Security- used t0 determine which classes a container supports, and to 

Manager for authorizing users to tasks and object data. ma P 10 data tne specific container type needed to support 

Specifically, SecurityManager defines methods checkRead 45 persisting instances of that class. For example, for an ODBC 

0, checkWriteO, checkCreateO and checkDeleteO for container, the configuration object contains the class name 

checking authority for reading, writing, creating and delet- of me schema mapping class that provides the logic neces- 

ing entities, respectively. Varying levels and types of secu- sarv for performing the transformation from object schema 

rity may be provided by the SecurityManager, such as user t0 relational schema. These objects contain a reference to 

security and server process security. 50 one or raore ContainerStoreConfig objects described below. 

A persistent storage environment requires a framework ContainerStoreConfig is an abstract extensible class that 

consumer to extend several classes that collectively define a defines a container store that represents an extent of storage 

persistent storage environment. Generally, a persistent stor- that a container has configured to use. For example, for an 

age environment is created by creating or specifying sub- ODBC container, the ContainerStoreConfig objects would 

classes from the following classes: PersistentContainer, 55 define the table or set of tables occupied by this class in the 

ContainerClassConfig; ContainerConfig; ResourceConfig, relational database over which the container is defined. For 

and ContainerStoreConfig. ContainerConfig is an abstract single-level store (SLS) containers, this object contains 

extensible class that defines configuration data correspond- information such as the SLS pool. 

ing to one or more persistent containers. This configuration Resource is an abstract extensible class that identifies one 

data includes the container ID value that is assigned when 60 or more resources that correspond to a particular persistent 

the container is configured. This container ID is stored in all storage environment. The PersistentContainer is responsible 

persistent handles created by framework 870. Container- for creating, initializing and registering a Resource object to 

Config includes methods getConlainer(), the corresponding Transaction Manager. The class Transac- 

getContainerClassConfigsO and gelResourceConfigQ which tionManager is a core class that has a "has" relationship with 

return the container name, the ContainerGassConfig object 65 the Resource class, indicating that an object instantiated 

and the ResourceConfig object, respectively, that correspond under the TransactionManager class has one or more corre- 

to the persistent storage environment that ContainerConfig is sponding resource objects. TransactionManager carries out 
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the transaction control by interacting with objects of the Referring now to the class diagram of 1 7 1G. 12, the 
extensible Resource class that are registered to it. Resource- PersistentContainer class has been subclassed to define a 
Manager is a concrete core class that maintains a list of single-level store (SLS) container and an abstract two-level 
available and used transactional resources that are available store (TLS) container. The TLS container is further sub- 
for use by a particular thread. The PersistentContainer 5 classed to define an OdbcContainer, a PosixConlainer, and a 
interfaces with the ResourceManager class to obtain the JdbcContainer. The SLS, ODBC, Posix and JDBC contain- 
necessary transactional resource to use for any given con- ers in FIG. 12 are examples of concrete containers defined 
tainer method. The Resource objects are registered with the by appropriate subclassing of the PersistentContainer class, 
transaction service and the objects stored in the container are In addition to subclassing from PersistentContainer, a 
registered to the Resource. Thus, the TransactionManager 10 framework consumer must also subclass from the Handle 
(i.e., transaction service) maintains a reference to the class to define concrete handles for each persistent container. 
Resource, which maintains references to all the CachedEn- For the example of FIG. 12, appropriate subclassing of the 
tity Instances that have been registered to the transaction. abstract Handle class is shown in FIG. 13. Specifically, 
ResourceManager has a "has" relationship with the Handle is subclassed to define an SLSHandle and a TLS- 
Resource class, indicating that an object instantiated under 15 Handle. Furthermore, the abstract TLSI landle is subclassed 
the ResourceManager class has one or more corresponding to define a Legacy Handle and a Non- Legacy Handle. SLS- 
Resource objects. Extensibility of the Resource objects that Handle defines a handle that may be used to identify objects 
are referenced by the ResourceManager is required in order in the SLSContainer class. LegacyHandle defines a handle 
for framework consumers to add additional persistent stor- that may be used as a legacy key for rational databases such 
age systems (i.e., datastores) to a system defined by frame- 20 as the OdbcContainer and JdbcContainer. The Non- 
work 870. Extensibility is achieved by the way in which the LegacyHandle is a handle that may be used by containers 
ResourceManager and PersistentContainer interact to obtain that do not use legacy keys, such as PosixContainer. 
an appropriate Resource for the request. The Persist entCon- Referring to FIG. 14, appropriate subclassing of the 
tainer passes the ResourceConfig object that is referenced by Resource class is shown to define different types of 
the ContainerConfig object. The ResourceConfig class con- 25 resources. Resource is subclassed to define a TwoPhaseR- 
tains both a resource type (which must be enforced to be esource class, which is an abstract extensible class. Syn- 
unique) and a Resource class. Because this ContainerConfig chronizedRcsource is further subclassed from TwoPhaseR- 
object itself is configurable, each container can be set up to esource to define a two phase resource that is synchronized, 
use the appropriate Resource class. Synchronized Resource is then subclassed to define several 

DistributedThreadContext (DTC) is a core class that 30 concrete subclasses, namely: PosixResource, 

defines a context for one or more distributed threads used in OdbcResource, Jdbc Resource, and XA Resource. These 

a distributed object system. DTC has a "has" relationship resources are responsible for handling the transaction flows 

with the ResourceManager class, indicating that one or more during commit, rollback, and recovery processing. PosixRe- 

DistributedThreadContext objects has a corresponding source is a resource that is implemented for Posix files. 

ResourceManager. DTC also has a "has" relationship with 35 OdbcResource performs single-phase commit on ODBC 

the ConnectionManager class, indicating that each DTC has connections, and is only valid on ODBC containers. XARe- 

a corresponding ConnectionManager. source is a resource that performs two-phase commit against 

ConnectionManager is a concrete core class that operates a relational database (such as an ODBC or JDBC) using XA 
similar to the ResourceManager. Each Resource type is interfaces according to the X/OPEN XA standard that 
allocated a bucket of connections to use for its communi- 40 defines transactional activity program interfaces (APIs) for 
cation to the datastore for any given DistributedThreadCon- two-phase commitment control. XAResource is used to 
text. Thus, each distributed thread has a set of connection perform a two-phase commit against cither ODBC or JDBC. 
buckets equal to the number of Resource types currently JdbcResource provides single-phase commit for JDBC con- 
configured in the network. The concrete persistent container tamers. The JDBC APIs for single -phase commitment are 
classes ask for a connection from the ConnectionManager 45 different than ODBC APIs for single-phase commit, and thus 
and pass the container reference. The ConnectionManager a different implementation for JdbcResource is necessary, 
then uses the ContainerConfig object to get to the Resource- The class diagram of FIG. 15 illustrates further subclass- 
Config object for the container. This ResourceConfig object ing to define ODBC, Posix and SLS persistent storage 
contains the unique resource type for the Resource. This environments. Due to the similarity in methods and required 
allows the ConnectionManager to locate the bucket of 50 data, the ClassConfig, ContainerClassConfig, 
interest. Once the correct bucket is determined, the Connec- ContainerConfig, ResourceConfig, and Containers toreCon- 
tionManager invokes an abstract method on the Persistent- fig classes are all subclassed from a common ConfigBase 
Container object to get the connection key that defines abstract extensible class. Each of the following classes are 
which Connection within the bucket will satisfy the get subclassed to provide the concrete subclasses used by frame- 
connection request. This allows each concrete persistent 55 work 870: ContainerClassConfig, ContainerConfig, 
container the ability to indicate the connection string that ResourceConfig, and ContainerStoreConfig. OdbcClass- 
will satisfy its connection requirements. Note that Connec- Config defines a concrete class configuration for an ODBC 
tionManager has a "has" relationship with the Connection PersistentContainer; OdbcContainerConlig defines a con- 
class, indicating that each ConnectionManager object has crete container configuration for an ODBC PersistentCon- 
one or more corresponding Connections that it manages. 60 tainer; OdbcResourceConfig defines a single-phase commit 
Connections is an abstract extensible class that defines a resource configuration for an ODBC PersistentContainer; 
connection that may be used to satisfy connection requests, XAResourceConfig defines a two-phase commit resource 
such as OdbcConnection and PosixConnection. configuration for an ODBC PersistentContainer; and RDB- 

All of the relationships between classes in FIG. 11 are StorcConfig defines a container store configuration for an 

core relationships, which a user of the framework may not 65 ODBC PersistentContainer. 

alter. As such, they are part of the core function of frame- In similar manner, PosixClassConfig, 

work 870. PosixContainerConfig, Posix ResourceConfig, and PosixS- 
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toreConfig define concrete subclasses for these classes for a make up any persistent storage environment depend on how 

Posix PersistentContainer, and SLSClassConfig, the user of the framework extends the classes and defines (or 

SLSContainerConfig, SLSRcsourceConfig, and SLSStore- overrides) the appropriate methods. 

Config define concrete subclasses for these classes for an yh e core function of framework 870 is partially defined 

SLS PersistentContainer. 5 by core methods in the PersistentContainer class, as 

FIGS. 12-15 illustrate that framework 870 may be described above. These methods provide for overall control 

extended to define a number of different persistent storage of the persistence services and ensures that operations are 

environments. For the specific ODBC example shown in performed in the appropriate logical sequence. The core 

FfGS. 12-16, an ODBC persistent storage environment is methods defined by PersistentContainer are intended to be 

defined by extending the framework to define the following i° common to all persistent storage environments. These core 

concrete subclasses: OdbcContainer (FIGS. 12 & 16), Non- methods ensure that the following types of functions are 

Legacyllandlc (FIGS. 13 and 16), OdbcResource (FIGS. 14 performed in the correct sequence: registering entities to the 

and 16), XAResource (FIG. 16), OdbcClassConfig (FIG. transaction, locking entities, invoking security control of 

15), OdbcContainerConfig(FIGS. 15 & 16), OdbcResource- entities, caching entities, and obtaining connections to the 

Config (FIG. 15),XAResourceConfig(FIG. 15), RDBStore- is datastore that will store the entities. 
Config (FIG. 15), CacheManagerl (FIG. 16), LockManagerl 

(FIG. 16), SecurityManagerl (FIG. 16). In similar manner, a Object Interaction 

Posix or JDBC persistent storage environment may be m operation of lhe f ramew ork of FIG. 11 may be best 

defined by extending the framework to define appropriate understood by the class diagrams of FIGS. 11-16 and the 

concrete subclasses. 20 diagram of FIG 17 Many d ifj erent persistent storage 

PersistentContainer defines a set of methods, some of environments may be created by defining concrete 

which are extensible and some of which are core. The core subclasses, as explained above with reference to FIGS, 

methods within PersistentContainer include: createEntityO, 12-15. Of course, many more persistent storage environ- 

getEntity(), deleteEntity(), dropAccessO, refreshEntityO, men is may be implemented with the framework. If a per- 

syncEntity(), and updateEntity(). The core methods in Per- 25 sistent st0 rage environment has the same common features 

sistentContainer are defined by framework 870, and may not w j tn a different environment that is already implemented in 

be modified by the user. Extensible methods within Persis- the f rame work, the new environment may use the same 

tentContainer include doCreateEntityO, doGetEntityO, and subclass without having to duplicate the effort to re-generate 

doOeleteEntityO, which are defined in subclasses of Persis- tnc codc r rom scrat ch. From this we see the power and 

tentContainer to perform these functions for a particular 30 flexibility of providing a persistent storage framework. In 

persistent storage environment. The core methods within surtu the f rarncwor k not only makes the programmer's job 

PersistentContainer invoke the extensible methods in con- cas i er> but j t ^ makes the ^dc mucn more porta ble to 

crete subclasses of PersistentContainer when appropriate to other applications, and makes the code much easier to 

perform datastore-specific logic. For example, the maintain 

getEntityO core method in PersLstentContainer invokes a « ^ ^ ^ framewQrk g7() in accordance 

doGetEntityO method at the point .n time when it needs the wi , h (hc invention wj| , nQw be illuslrated wi(h 

des.red container subclass logic to actual y perform the Kbtmgi lQ the ;fic ^ e environmenl 

necessary interaction with the datastore to retrieve the entity shown .„ r ., G „ which b aQ object j. * of onf , , e 

from persistent storage, lhe getEntityO method performs ■ . . , „ * u- u <• c 

v . t B r f / v „ , X 4n persistent storage environment which, tor purposes of 

numerous lunctions before and alter the call to doGetEntity illustrali js , he 0DBC persistent slorage environment. 

f ^o X P 1 7 ained ^ WUh reterenCe 10 ,hC ° bjeCt diagram The function of the framework mechanism will now be 
0 described with reference to the specific methods referenced 
Core Functions in FIG. 17. 
FIG. 11 best distinguishes between core and extensible 45 We assume that a client object we arbitrarily name 
functions in the persistent storage framework of the present "caller" invokes the framework 870 by calling the 
invention. Specifically, as noted above, many of the classes getEntityO method on the OdbcContainer object. First we 
in this framework are extensible classes, and some are core must determine whether the requested entity exists in the 
classes. The core classes include: AccessMode, cache. To do this, OdbcContainer invokes the 
CachedEntitylnstance, Tra nsactio nManager, 50 getCachedEntity() method on the ContainerCacheMa- 
ResourceManager, DistributedThreadContext, and Connec- nangcrl object. This example assumes that the entity is not 
tionManager. All class relationships in framework 870 are in cache, so the entity must be retrieved from persistent 
core relationships, and may not be modified by the user of storage. The next step is to invoke the getConfigO method on 
the framework. In fact, it is the fixed character of these the ContainerConfig object (step 3) to determine the con- 
relationships between classes that characterizes a framework 55 figuration of the ODBC container that contains the entity. A 
and makes it useful and powerful. The core function of the new CachedEntitylnstance object is then instantiated (step 
persistent storage framework is defined by the core classes, which is a wrapper object for the entity to be retrieved 
the core class relationships, and the functional requirements (^d stored later in the cache). Next, the OdbcContainer 
that cause the framework to behave in the desired manner. object invokes a constructor method newlnstance() on the 
As described above with respect to FIG. 9, the overall core 60 entit y (step 5), which we call for this example Foo, thereby 
function of the persistent storage framework includes the creating an entity that does not yet have the appropriate date, 
steps of method 900. Note, however, that not all of the steps At this point, the transaction identifier for this transaction is 
of method 900 need be implemented in a particular persis- determined by invoking the ge transaction I D() method on 
lent storage environment. The various functions of FIG. 9 lhe Transaction Manager object (step 6). 
are core functions not because they arc always performed, 65 Next, OdbcContainer invokes the 
but because the framework provides support for the irnple- get Registered ResourceQ method on the OdbcResourceM- 
mentation of each of these steps. The specific steps that anager object (step 7) to determine the resource that corre- 
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sponds to the ODBC datastore. The 
get Registered Resource () method returns the name of the 
resource, which in this particular example is Odbc Resource. 
OdbcContainer then invokes the registerObject0 method on 
OdbcResource (step 8) to register the entity with the appro- 
priate resource. Next, OdbcContainer invokes 
checkGelEntityO on the SecurityManagerl object (step 9) to 
verify that the caller has sufficient security clearance to 
access the requested entity. 

OdbcContainer then invokes the lockEntityO method on 
the LockManagerl object (step 10) to assure that the entity 
is not already locked, and to lock the entity for the duration 
of the current transaction. At this point all the needed checks 
have been performed, and the entity is accessed by invoking 
the doGetEntityO method on OdbcContainer (step II), 
which delegates the functions required to retrieve the entity 
from the ODBC datastore to the appropriate concrete sub- 
classes that know how to access the entity. The 
doGetEntityO method first invokes the getConnectionQ 
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a container configuration class defining: 

at least one container configuration object that contains 
configuration data corresponding to at least one of a 
plurality of persistent containers; and 
a second set of object methods to return the name of the 
persistent container and to identify at least one object 
that contains additional information regarding the 
persistent storage environment; 
a container class configuration class defining: 

at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which 
classes the at least one persistent container supports; 
a container store configuration class defining: 

at least one container store configuration object that 
contains configuration data that defines a container 
store that represents an extent of storage that a 
persistent container has configured to use. 
2. The apparatus of claim I wherein the framework 



method on the ConnectionManager object (step 12), which 20 mec h an ism comprises a persistent container class, the per 



returns the connection for retrieving the entity. Next, 
doGetEntityO invokes the getSchemaMapper() method on 
the appropriate connection corresponding to the ODBC 
datastore (step 13), which returns the OdbcSchemaMapper 
as the schema mapper that corresponds to the ODBC datas- 
tore. The doGetEntityO method then invokes the restore() 
method on the OdbcSchemaMapper object (step 14), which 
fluffs up the Foo object from the data stored in the ODBC 
datastore and stores this in cacheable form in the Cache - 
dEntitylnstance. Finally, OdbcContainer invokes the 
addCachedEntily() method on the ContainerCacheMan- 
agerl object (step 15), which adds the CachcdEntitylnstancc 
to the cache. 

As the example above illustrates, the framework provides 
an extremely flexible and powerful tool for implementing 
any number of persistent storage environments by simply 
defining classes that implement the features specific to a 
particular persistent storage environment. The core methods 
defined by the PcrsistentContainer class interact with exten- 
sible methods to perform all needed functions in a particular 
persistent storage environment. 

The embodiments and examples set forth herein were 
presented in order to best explain the present invention and 
its practical application and to thereby enable those skilled 
in the art to make and use the invention. However, those 
skilled in the art will recognize that the foregoing descrip- 
tion and examples have been presented for the purposes of 
illustration and example only. The description as set forth is 
not intended to be exhaustive or to limit the invention to the 
precise form disclosed. Many modifications and variations 
are possible in light of the above teaching without departing 
from the spirit and scope of the forthcoming claims. Note 
that the term "user" or "framework consumer" as used in the 
specification and the claims denotes any human programmer 
or any software program that is capable of extending the 
framework mechanism to define a particular persistent stor- 
age environment. 

We claim: 

1. An apparatus comprising: 
at least one processor; and 

a memory coupled to the at least one processor, the 
memory containing an object-oriented framework 
mechanism that provides at least one persistent storage 
environment, the framework mechanism executing on 
the at least one processor, the framework mechanism 
comprising: 
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sistent container class defining: 

at least one persistent container object for storing at least 
one object in the at least one persistent storage envi- 
ronment; and 

a first set of object methods to perform a plurality of 
predetermined functions to at least partially implement 
the persistent storage environment. 

3. The apparatus of claim 2 wherein the first set of object 
methods includes: 

at least one object method that creates at least one object 

and stores the at least one object in the persistent 

container object; 
at least one object method that retrieves at least one object 

from the persistent container object; and 
at least one object method that deletes at least one object 

from the persistent container object. 

4. The apparatus of claim 2 wherein the persistent con- 
tainer class is an extensible class of the framework 
mechanism, the implementation of which by a user at least 
partially defines the persistent storage environment. 

5. The apparatus of claim 1 wherein the container con- 
figuration class, the container class configuration class, and 
the container store configuration class are extensible classes 
of the framework mechanism, the implementation of which 
by a user at least partially defines the persistent storage 
environment. 

6. The apparatus of claim 1 wherein the framework 
mechanism further comprises: 

a resource class defining: 

at least one resource object corresponding to at least 
one transactional resource in the persistent storage 
environment; 
a resource configuration class defining: 

at least one resource configuration object that contains 
configuration data for the at least one resource 
object; 

a resource manager class defining: 

at least one resource manager object that contains a list 
of transactional resources that are available for use. 

7. The apparatus of claim 6 wherein the framework 
mechanism further comprises: 

a transaction manager class defining: 

at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 
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a lock manager class defining: 

ai least one lock manager object thai provides control 
of concurrent accesses to at least one object in the 
persistenl storage environment; and 

a third set of object methods for locking and unlocking 
at least one object in the persistent storage environ- 
ment; 

a cache manager class defining: 

at least one cache manager object that manages at least 

one object in a cache; 
a fourth set of object methods for retrieving, storing, 
and deleting the at least one object in the cache; 
a security manager class defining: 

at least one security manager object that checks for 
proper authorization to access at least one object in 
the persistent storage environment; and 
a connection manager class defining: 

at least one connection manager object that allocates at 
least one connection for a transaction. 

8. The apparatus of claim 7 wherein the framework 
mechanism further comprises: 

an access mode class defining: 

at least one access mode object that interacts with the 
at least one lock manager object to determine how at 
least one object in the persistent storage environment 
may be accessed; 
a lock class defining: 

at least one lock object that determines whether at least 
one object in the persistent storage environment is in 
a locked slate; 
a conneclion class defining: 

at least one connection object corresponding to a con- 
nection that may be allocated by the connection 
manager object to a transaction; 
a distributed thread context class defining: 

at least one distributed thread context object that pro- 
vides a context for at least one distributed thread 
used in the persistent storage environment; 
a handle class defining: 

at least one handle object containing an identifier for 
uniquely identifying each object in the persistent 
storage environment. 

9. The apparatus of claim 8 wherein the framework 
mechanism comprises: 

a class configuration class defining: 

at least one class configuration object that contains a 
fully qualified class name corresponding to an object 
identifier in the persistent storage environment; and 

a fifth set of object methods for determining the class 
name from the object identifier and for determining 
the object identifier from the class name; 
a cached entity instance class defining: 

at least one cached entity instance object containing an 
in-memory representation of at least one object in the 
persistent storage environment. 

10. The apparatus of claim 9 wherein the persistent 
container class has a "has" relationship with the cache 
manager class, the container configuration class, and the 
lock manager class. 

11. The apparatus of claim 9 wherein the persistent 
container class has a "using" relationship with the resource 
class, the transaction manager class, the resource manager 
class, the access mode class, and the security manager class. 

12. The apparatus of claim 1 wherein the memory con- 
tains an application program that supports an object-oriented 
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programming environment containing the framework 
mechanism, and wherein the framework mechanism is 
extended by providing information that implements the ai 
leasi one persistent storage environment. 

13. The apparatus of claim 1 wherein the framework 
mechanism comprises: 

at least one core function defined by at least one core class 
and by the relationships between a plurality of classes 
within the framework mechanism, wherein the imple- 
mentation of the at least one core function is defined by 
the framework mechanism and cannot be modified by 
a user of the framework mechanism; and 

at least one extensible function defined by at least one 
extensible class, wherein the implementation of the at 
least one extensible function is defined by the user of 
the framework mechanism by extending the at least one 
extensible class. 

14. An apparatus comprising: 
at least one processor; and 

a memory coupled to the at least one processor, the 
memory containing an object-oriented framework 
mechanism that provides at least one persistent storage 
environment, the framework mechanism executing on 
the at least one processor, the framework mechanism 
comprising: 
a resource class defining: 

at least one resource object corresponding to at least 
one transactional resource in the persistent storage 
environment; 
a resource configuration class defining: 

at least one resource configuration object that contains 
configuration data for the at least one resource 
object; 

a resource manager class defining: 

at least one resource manager object that contains a list 
of transactional resources that are available for use, 

15. The apparatus of claim 14 wherein the resource class 
and the resource configuration class are extensible classes of 
the framework mechanism, the implementation of which by 
a user at least partially defines the persistent storage envi- 
ronment; and wherein the resource manager class is a core 
class of the framework mechanism, the implementation of 
which cannot be modified by the user. 

16. An apparatus comprising: 
at least one processor; and 

a memory coupled to the at least one processor, the 
memory containing an object-oriented framework 
mechanism that provides at least one persistent storage 
environment, the framework mechanism executing on 
the at least one processor, the framework mechanism 
comprising: 
a transaction manager class defining: 

at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 
a lock manager class defining: 

at least one lock manager object that provides control 
of concurrent accesses to at least one object in the 
persistent storage environment; and 
a Ihird set of object methods for locking and unlocking 
at least one object in the persistent storage environ- 
ment; 

a cache manager class defining: 

at least one cache manager object that manages at least 
one object in a cache; 
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a fourth set of object methods for retrieving, storing, and 

deleting the at least one object in the cache; 
a security manager class defining: 

at least one security manager object that checks for 
proper authorization to access at least one object in 
the persistent storage environment; and 
a connection manager class defining: 

at least one connection manager object that allocates at 
least one connection for a transaction. 

17. The apparatus of claim 16 wherein the lock manager 
class, the cache manager class, and the security manager 
class are extensible classes of the framework mechanism, 
ihe implementation of which by a user al least partially 
defines the persistent storage environment; and wherein the 
transaction manager class and the connection manager class 
are core classes of the framework mechanism, the imple- 
mentation of which cannot be modified by the user. 

18. The apparatus of claim 16 wherein the framework 
mechanism further comprises: 

an access mode class defining: 

at least one access mode object that interacts with the 
at least one lock manager object to determine how at 
least one object in the persistent storage environment 
may be accessed; 
a lock class defining: 

at least one lock object that determines whether at least 
one object in the persistent storage environment is in 
a locked state; 
a connection class defining: 

at least one connection object corresponding to a con- 
nection that may be allocated by the connection 
manager object to a transaction; 
a distributed thread context class defining: 

at least one distributed thread context object that pro- 
vides a context for at least one distributed thread 
used in the persistent storage environment; 
a handle class defining: 

at least one handle object containing an identifier that 
uniquely identifies each object in the persistent stor- 
age environment. 
.19. The apparatus of claim 18 wherein the lock class, the 
connection class, and the handle class are extensible classes 
of the framework mechanism, the implementation of which 
by a user at least partially defines the persistent storage 
environment; and wherein the access mode class and the 
distributed thread context class are core classes of the 
framework mechanism, the implementation of which cannot 
be modified by the user. 

20. An apparatus comprising: 
at least one processor; and 

a memory coupled to the at least one processor, the 
memory containing an object-oriented framework 
mechanism that provides at least one persistent storage 
environment, the framework mechanism executing on 
the at least one processor, the framework mechanism 
comprising: 
a class configuration class defining: 

at least one class configuration object that contains a 
fully qualified class name corresponding to an object 
identifier in the persistent storage environment; and so 
a fifth set of object methods for determining the class 
name from the object identifier and for determining 
the object identifier from the class name; and 
a cached entity instance class defining: 
at least one cached entity instance object containing an 65 
in-rnemory representation of al least one object in the 
persistent storage environment. 
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21. The apparatus of claim 20 wherein the class conlij-.u- 
ration class is an extensible class of the framework 
mechanism, the implementation of which by a user at least 
partially defines the persistent storage environment; and 
wherein the cached entity instance class is a core class of the 
framework mechanism, the implementation of which cannot 
be modified by the user. 

22. A method for supporting persistence of at least one 
object in an object-oriented system by providing at least one 
persistent container, the method comprising the steps of: 

providing an extensible object-oriented framework 
mechanism that provides the al least one persistent 
container according to extended portions of the frame- 
work mechanism that are customized to provide a 
desired persistent storage environment: and 

executing the object-oriented framework mechanism on 
an apparatus, the executing object oriented framework 
mechanism performing the steps of: 

(a) checking a cache to determine if the at least one 
object is present in the cache; 

(b) determining the configuration for a selected persis- 
tent container; 

(c) allocating a transaction identifier to the at least one 
object; and 

(d) allocating a resource corresponding to the transac- 
tion identifier to the at least one object. 

23. The method of claim 22 further including the step of: 
extending the framework mechanism to define the desired 

persistent storage environment. 

24. The method of claim 22 further including the steps of: 

(e) checking the security of a client object that desires to 
access the at least one object in the persistent container; 

(f) checking the lock state of the at least one object in the 
persistent container; and 

(g) fluffing up the at least one object in the persistent 
container; 

(h) storing the fluffed up object in the cache; and 

(i) returning the fluffed up object to the client object. 

25. The method of claim 24 wherein the step of fluffing up 
the at least one object includes the steps of: 

providing extensible portions of the framework mecha- 
nism that determine how the at least one object is 
created, stored, and retrieved from the persistent con- 
tainer; and 

the extensible portions retrieving state data from the 
persistent container corresponding to the at least one 
object and creating the at least one object from the state 
data. 

26. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 
vides at least one persistent storage environment, the 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 
framework mechanism comprises: 

a persistent container object corresponding to the at least 
one persistent storage environment; and 

a first set of object methods on the persistent container 
object to perform a plurality of predetermined functions 
to implement the persistent storage environment, 

the first set of object methods includes: 

at least one object method that creates at least one 
object and stores the at least one object in the 
persistent container object; 
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at least one object method that retrieves at least one 

object from the persistent container object; and 
at least one object method that deletes at least one 
object from the persistent container object; and 
(B) signal bearing media bearing the framework mecha- 
nism. 

27. The program product of claim 26 wherein the signal 
bearing media comprises recordable media. 

28. The program product of claim 26 wherein the signal 
bearing media comprises transmission media. 

29. The program product of claim 26 wherein the frame- 
work mechanism further comprises: 

at least one container configuration object that contains 
configuration data corresponding to at least one of a 
plurality of persistent containers; 

a second set of object methods to return the name of the 
persistent container and to identify at least one object 
that contains additional information regarding the per- 
sistent storage environment; 

at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which classes 
the at least one persistent container supports; and 

at least one container store configuration object that 
contains configuration data that defines a container 
store that represents an extent of storage that a persis- 
tent container has configured to use. 

30. The program product of claim 29 wherein the frame- 
work mechanism further comprises: 

at least one resource object corresponding to at least one 
transactional resource in the persistent storage environ- 
ment; 

at least one resource configuration object that contains 
configuration data for the at least one resource object; 

at least one resource manager object that contains a list of 
transactional resources that are available for use. 

31. The program product of claim 30 wherein the frame- 
work mechanism further comprises: 

at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 

at least one lock manager object that provides control of 
concurrent accesses to at least one object in the per- 
sistent storage environment; 

a third set of object methods for locking and unlocking at 
least one object in the persistent storage environment; 

at least one cache manager object that manages at least 
one object in a cache; 

a fourth set of object methods for retrieving, storing, and 
deleting the at least one object in the cache; 

at least one security manager object that checks for proper 
authorization to access at least one object in the per- 
sistent storage environment; and 

at least one connection manager object that allocates at 
least one connection for a transaction. 

32. The program product of claim 31 wherein the frame- 
work mechanism further comprises: 

at least one access mode object that interacts with the at 
least one lock manager object to determine how at least 
one object in the persistent storage environment may be 
accessed; 

at least one lock object that determines whether at least 
one object in the persistent storage environment is in a 
locked state; 
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at least one connection object corresponding to a connec- 
tion that may be allocated by the connection manager 
object to a transaction; 

at least one distributed thread context object that provides 
a context for at least one distributed thread used in the 
persistent storage environment; and 

at least one handle object containing an identifier that 
uniquely identifies each object in the persistent storage 
environment. 

33. The program product of claim 32 wherein the frame- 
work mechanism further comprises: 

at least one class configuration object that contains a fully 
qualified class name corresponding to an object iden- 
tifier in the persistent storage environment; 

a fifth set of object methods for determining the class 
name from the object identifier and for determining the 
object identifier from the class name; and 

at least one cached entity instance object containing an 
in-memory representation of at least one object in the 
persistent storage environment. 

34. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 
vides at least one persistent storage environment, the 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 
framework mechanism comprises: 

at least one container configuration object that contains 
configuration data corresponding to at least one of a 
plurality of persistent containers; 

a second set of object methods to return the name of the 
persistent container and to identify at least one object 
that contains additional information regarding the 
persistent storage environment; 

at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which 
classes the at least one persistent container supports; 
and 

at least one container store configuration object that 
contains configuration data that defines a container 
store that represents an extent of storage that a 
persistent container has configured to use; and 

(B) signal bearing media bearing the framework mecha- 
nism. 

35. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 
vides at least one persistent storage environment, the 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 
framework mechanism comprises: 

at least one resource object corresponding to at least 
one transactional resource in the persistent storage 
environment; 

at least one resource configuration object that contains 
configuration data for the at least one resource 
object; 

at least one resource manager object that contains a list 
of transactional resources that are available for use; 
and 

(B) signal bearing media bearing the framework mecha- 
nism. 
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36. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 
vides a l least one persistent storage environment, the 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 5 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 
framework mechanism comprises: 

at least one transaction manager object that manages a 
transaction by interacting with at least one object ]Q 
corresponding to a transactional resource; 

at least one lock manager object that provides control 
of concurrent accesses to at least one object in the 
persistent storage environment; 

a third set of object methods for locking and unlocking 
at least one object in the persistent storage environ- 15 
ment; 

at least one cache manager object that manages at least 

one object in a cache; 
a fourth set of object methods for retrieving, storing, 

and deleting the at least one object in the cache; 20 
at least one security manager object that checks for 

proper authorization to access at least one object in 

the persistent storage environment; and 
at least one connection manager object that allocates at 

least one connection for a transaction; and 25 

(B) signal bearing media bearing the framework mecha- 
nism. 

37. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 
vides at least one persistent storage environment, the 30 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 
framework mechanism comprises: 35 
at least one access mode object that interacts with the 

at least one lock manager object to determine how at 
least one object in the persistent storage environment 
may be accessed; 

at least one lock object that determines whether at least 40 
one object in the persistent storage environment is in 
a locked state; 

at least one connection object corresponding to a con- 
nection that may be allocated by the connection 
manager object to a transaction; 45 

at least one distributed thread context object that pro- 
vides a context for at least one distributed thread 
used in the persistent storage environment; and 

at least one handle object containing an identifier that 
uniquely identifies each object in the persistent stor- 50 
age environment; and 

(B) signal bearing media bearing the framework mecha- 
nism. 

38. A program product comprising: 

(A) an object-oriented framework mechanism that pro- 55 
vides at least one persistent storage environment, the 
framework mechanism including an extensible persis- 
tent storage mechanism that provides the at least one 
persistent storage environment according to extended 
portions of the framework mechanism, wherein the 60 
framework mechanism comprises: 
at least one class configuration object that contains a 
fully qualified class name corresponding to an object 
identifier in the persistent storage environment; 
a fifth set of object methods for determining the class 65 
name from the object identifier and for determining 
the object identifier from the class name; and 
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at least one cached entity instance object containing an 
in-memory representation of at least one object in the 
persistent storage environment; and 
(B) signal bearing media bearing the framework mecha- 
nism. 

39. An object-oriented framework mechanism for use in 
an apparatus that supports an object-oriented programming 
environment, the framework mechanism comprising: 
a persistent container object corresponding to the at least 
one persistent storage environment and a first set of 
object methods on the persistent container object to 
perform a plurality of predetermined functions to 
implement the persistent storage environment; 
at least one container configuration object that contains 
configuration data corresponding to at least one of a 
plurality of persistent containers and a second set of 
object methods to return the name of the persistent 
container and to identify at least one object that con- 
tains additional information regarding the persistent 
storage environment; 
at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which classes 
the at least one persistent container supports; 
at least one container store configuration object that 
contains configuration data that defines a container 
store that represents an extent of storage that a persis- 
tent container has configured to use; 
at least one resource object corresponding to at least one 
transactional resource in the persistent storage environ- 
ment; 

at least one resource configuration object that contains 
configuration data for the at least one resource object; 
at least one resource manager object that contains a list of 

transactional resources that are available for use; 
at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 
at least one lock manager object that provides control of 
concurrent accesses to at least one object in the per- 
sistent storage environment and a third set of object 
methods for locking and unlocking at least one object 
in the persistent storage environment; 
at least one cache manager object that manages at least 
one object in a cache and a fourth set of object methods 
for retrieving, storing, and deleting the at least one 
object in the cache; 
at least one security manager object that checks for proper 
authorization to access at least one object in the per- 
sistent storage environment; 
at least one connection manager object that allocates at 

least one connection for a transaction; 
at least one access mode object that interacts with the at 
least one lock manager object to determine how at least 
one object in the persistent storage environment may be 
accessed; 

at least one lock object that determines whether at least 
one object in the persistent storage environment is in a 
locked state; 

at least one connection object corresponding to a connec- 
tion that may be allocated by the connection manager 
object to a transaction; 
at least one distributed thread context object that provides 
a context for at least one distributed thread used in the 
persistent storage environment; 
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al least one handle object containing an identifier that 
uniquely identifies each object in the persistent storage 
environment; 

at least one class configuration object that contains a fully 
qualified class name corresponding to an object iden- 5 
lifter in the persistent storage environment and a fifth 
set of object methods for determining the class name 
from the object identifier and for determining the object 
identifier from the class name; and 

at least one cached entity instance object containing an 10 
in-memory representation of at least one object in the 
persistent storage environment. 

40. The object-oriented framework mechanism of claim 
39 wherein the framework mechanism comprises: 

at least one core function defined by relationships J5 
between a plurality of classes within the framework 
mechanism, wherein the implementation of the at least 
one core function is defined by the framework mecha- 
nism and cannot be modified by a user of the frame- 
work mechanism; and 

at least one extensible function defined by at least one 20 
extensible class, wherein the implementation of the at 
least one extensible function is defined by the user of 
the framework mechanism by extending the at least one 
extensible class. 

41. A method for supporting persistence of at least one 25 
object in an object-oriented system by providing at least one 
persistent container, the method comprising the steps of: 

(A) providing a persistent container object corresponding 
to the at least one persistent storage environment, the 
persistent container object including a first set of object 50 
methods on the persistent container object to perform a 
plurality of predetermined functions to implement the 
persistent storage environment; 

(B) providing a persistent container object corresponding 

to the at least one persistent storage environment and a 35 
first set of object methods on the persistent container 
object to perform a plurality of predetermined functions 
to implement the persistent storage environment; 

(C) providing at least one container configuration object 
that contains configuration data corresponding to at 40 
least one of a plurality of persistent containers and a 
second set of object methods to return the name of the 
persistent container and to identify at least one object 
that contains additional information regarding the per- 
sistent storage environment; 45 

(D) providing at least one container class configuration 
object that contains configuration data for at least one 
class in at least one persistent container that defines 
which classes the at least one persistent container ^ 
supports; 

(E) providing at least one container store configuration 
object that contains configuration data that defines a 
container store that represents an extent of storage that 

a persistent container has configured to use; 55 

(F) providing at least one resource object corresponding 
to at least one transactional resource in the persistent 
storage environment; 

(G) providing at least one resource configuration object 
that contains configuration data for the at least one $q 
resource object; 

(H) providing at least one resource manager object that 
contains a list of transactional resources that are avail- 
able for use; 

(I) providing at least one transaction manager object that 65 
manages a transaction by interacting with at least one 
object corresponding to a transactional resource; 
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(J) providing at least one lock Manager object that pro- 
vides control of concurrent accesses to at least one 
object in the persistent storage environment and a third 
set of object methods for locking and unlocking at least 
one object in the persistent storage environment; 

(K) providing al least one cache manager object that 
manages at least one object in a cache and a fourth set 
of object methods for retrieving, storing, and deleting 
the at least one object in the cache; 

(L) providing at least one security manager object that 
checks for proper authorization to access at least one 
object in the persistent storage environment; 

(M) providing al least one connection manager object that 
allocates at least one connection for a transaction; 

(N) providing at least one access mode object that inter- 
acts with the at least one lock manager object to 
determine how at least one object in the persistent 
storage environment may be accessed; 

(O) providing at least one lock object that determines 
whether at least one object in the persistent storage 
environment is in a locked state; 

(P) providing at least one connection object correspond- 
ing to a connection that may be allocated by the 
connection manager object to a transaction; 

(Q) providing al least one distributed thread context 
object that provides a context for at least one distrib- 
uted thread used in the persistent storage environment; 

(R) providing at least one handle object containing an 
identifier that uniquely identifies each object in the 
persistent storage environment; 

(S) providing at least one class configuration object that 
contains a fully qualified class name corresponding to 
an object identifier in the persistent storage environ- 
ment and a fifth set of object methods for determining 
the class name from the object identifier and for deter- 
mining the object identifier from the class name; 

(T) providing at least one cached entity instance object 
containing an in-memory representation of at least one 
object in the persistent storage environment; and 

(U) executing the object-oriented framework mechanism 
on an apparatus to implement the persistent storage 
environment. 

42. The method of claim 41 further including the step of: 
extending the framework mechanism to define the desired 

persistent storage environment. 

43. A program product comprising: 

(A) an object-oriented framework mechanism for sup- 
porting persistence of at least one object in an object- 
oriented system by providing at least one persistent 
container, the object-oriented framework including: a 
persistent container object corresponding to the at least 
one persistent storage environment and a first set of 
object methods on the persistent container object to 
perform a plurality of predetermined functions to 
implement the persistent storage environment; at least 
one container configuration object that contains con- 
figuration data corresponding to at least one of a 
plurality of persistent containers and a second set of 
object methods to return the name of the persistent 
container and to identify at least one object that con- 
tains additional information regarding the persistent 
storage environment; at least one container class con- 
figuration object that contains configuration data for at 
least one class in at least one persistent container that 
defines which classes the at least one persistent con- 
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taincr supports; at least one container store configura- 
tion object that contains configuration data that defines 
a container store that represents an extent of storage 
that a persistent container has configured to use; at least 
one resource object corresponding to at least one trans- 
actional resource in the persistent storage environment; 
at least one resource configuration object that contains 
configuration data for the at least one resource object; 
at least one resource manager object that contains a list 
of transactional resources that are available for use; at 
least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; at least one 
lock manager object that provides control of concurrent 
accesses to at least one object in the persistent storage 
environment and a third set of object methods for 
locking and unlocking at least one object in the per- 
sistent storage environment; at least one cache manager 
object that manages at least one object in a cache and 
a fourth set of object methods for retrieving, storing, 
and deleting the at least one object in the cache; at least 
one security manager object that checks for proper 
authorization to access at least one object in the per- 
sistent storage environment; at least one connection 
manager object that allocates at least one connection 
for a transaction; at least one access mode object that 
interacts with the at least one lock manager object to 
determine how at least one object in the persistent 
storage environment may be accessed; at least one lock 
object that determines whether at least one object in the 
persistent storage environment is in a locked state; at 
least one connection object corresponding to a connec- 
tion that may be allocated by the connection manager 
object to a transaction; at least one distributed thread 
context object that provides a context for at least one 
distributed thread used in the persistent storage envi- 
ronment; at least one handle object containing an 
identifier that uniquely identifies each object in the 
persistent storage environment; at least one class con- 
figuration object that contains a fully qualified class 
name corresponding to an object identifier in the per- 
sistent storage environment and a fifth set of object 
methods for determining the class name from the object 
identifier and for determining the object identifier from 
the class name; at least one cached entity instance 
object containing an in-memory representation of at 
least one object in the persistent storage environment; 
wherein the object-oriented framework mechanism 
provides persistence of the at least one object according 
to extended portions of the framework mechanism that 
are customized to provide the desired persistent storage 
environment; and 
(B) signal bearing media bearing the object-oriented 
framework mechanism. 

44. The program product of claim 43 wherein the signal 
bearing media comprises recordable media. 

45. The program product of claim 43 wherein the signal 
bearing media comprises transmission media. 

46. The program product of claim 43 wherein the persis- 
tent container class, the container configuration class, the 
container class configuration class, the container store con- 
figuration class, the resource configuration class, the 
resource class, the lock manager class, the cache manager 
class, the security manager class, the lock class, the con- 
nection class, the handle class, and the class configuration 
class are extensible classes of the framework mechanism, 
the implementation of which by a user defines the at least 
one persistent storage environment. 
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47. Th j . •» ,t i product of claim 46 wherein the resource 
manager d:iss, tin transaction manager class, the connection 
manager class, th.; access mode class, the distributed thread 
context class, and the cached entity instance class are core 

5 classes of the framework mechanism, the implementation of 
which cannot be modified by a user. 

48. An object-oriented framework mechanism that sup- 
ports persistence of at least one object in an object-oriented 
system by providing at least one persistent container, the 

10 framework mechanism comprising: 

at least one core function defined by relationships 
between a plurality of classes within the framework 
mechanism, wherein the implementation of the at least 
one core function is defined by the framework mecha- 
15 nism and cannot be modified by a user of the frame- 
work mechanism; 
at least one extensible class wherein the implementation 
of the at least one extensible class is defined by the user 
of the framework mechanism, by extending the at least 
one extensible class, thereby defining at least one 
persistent storage environment; 
a persistent container object corresponding to the at least 
one persistent storage environment and a first set of 
object methods on the persistent container object to 
perform a plurality of predetermined functions to 
implement the persistent storage environment; at least 
one container configuration object that contains con- 
figuration data corresponding to at least one of a 
plurality of persistent containers and a second set of 
object methods to return the name of the persistent 
container and to identify at least one object that con- 
tains additional information regarding the persistent 
storage environment; 
at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which classes 
the at least one persistent container supports; 
at least one container store configuration object that 
contains configuration data that defines a container 
store that represents an extent of storage that a persis- 
tent container has configured to use; 
at least one resource object corresponding to at least one 
transactional resource in the persistent storage environ- 
ment; 

at least one resource configuration object that contains 
configuration data for the at least one resource object; 
at least one resource manager object that contains a list of 

transactional resources that are available for use; 
at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 
at least one lock manager object that provides control of 
55 concurrent accesses to at least one object in the per- 
sistent storage environment and a third set of object 
methods for locking and unlocking at least one object 
in the persistent storage environment; 
at least one cache manager object that manages at least 
60 one object in a cache and a fourth set of object methods 
for retrieving, storing, and deleting the at least one 
object in the cache; 
at least one security manager object that checks for proper 
authorization to access at least one object in the per- 
65 sistent storage environment; 

at least one connection manager object that allocates at 
least one connection for a transaction; 



45 



50 



06/10/2002, EAST Version: 1.03.0002 



t), I ). 

39 

al leasl one access mode object thai interacts with the ;< 
least one lock manager object to determine how at leasi 
one object in the persistent storage environment may be 
accessed; 

at leasl one lock object that determines whether at least 5 
one object in the persistent storage environment is in a 
locked slate; 

at least one connection object corresponding to a connec- 
tion that may be allocated by the connection manager 
object to a transaction; 10 

at least one distributed thread context object that provides 
a context for at least one distributed thread used in the 
persistent storage environment; 

at least one handle object containing an identifier that 15 
uniquely identifies each object in the persistent storage 
environment; 

at least one class configuration object that contains a fully 
qualified class name corresponding to an object iden- 
tifier in the persistent storage environment and a fifth 20 
set of object methods for determining the class name 
from the object identifier and for determining the object 
identifier from the class name; and 

at least one cached entity instance object containing an 
in-memory representation of at least one object in the 25 
persistent storage environment. 

49. An object-oriented framework mechanism that sup- 
ports persistence of at least one object in an object-oriented 
system by providing at least one persistent container, the 
framework mechanism comprising: 30 

at least one core function defined by relationships 
between a plurality of classes within the framework 
mechanism, wherein the implementation of the at least 
one core function is defined by the framework mecha- 
nism and cannot be modified by a user of the frame- 35 
work mechanism; 

at least one extensible class wherein the implementation 
of the at least one extensible class is defined by the user 
of the framework mechanism, by extending the at least 
one extensible class, thereby defining at least one 40 
persistent storage environment; 

a persistent container class; 

a container configuration class; 

a resource class; 45 

a resource manager class; 

a transaction manager class; 

a lock manager class; 

a cache manager class; 

1 50 
a security manager class; 

an access mode class; 

wherein the persistent container class has a "has" rela- 
tionship with the cache manager class, the container 
configuration class, and the lock manager class, and 55 
further has a "using" relationship with the resource 
class, the transaction manager class, the resource man- 
ager class, the access mode class, and the security 
manager class. 

50. A method for providing persistence of at least one go 
object in an object-oriented system by providing at least one 
persistent container using an apparatus having at least one 
processor and a memory, the memory having an application 
program that provides an object-oriented programming 
environment, the method comprising the steps of: 55 

(A) providing in (he program an object-oriented frame- 
work mechanism that defines a persistent storage sys- 
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tern according to extended portions of the framework 
mechanism that are customized to provide a desired 
persistent storage environment, the framework mecha- 
nism including: 

a set of core functions wherein the implementation of 
the core functions is defined by the framework 
mechanism and cannot be modified by a user of the 
framework mechanism; and 

a set of extensible functions wherein the implementa- 
tion of the extensible functions is defined by the user 
of the framework mechanism; 

(B) extending the extensible functions in the framework 
mechanism to define particular classes having prede- 
termined protocols and defining particular object meth- 
ods that define the persistent storage system, the exten- 
sible functions defining the desired persistent storage 
environment; 

(C) generating an executable persistent storage system by 
integrating together the extensible functions and the 
core functions; and 

(D) executing the executable persistent storage system on 
the apparatus to define the persistent storage environ- 
ment. 

51. The method of claim 50 further including the steps of: 

(a) checking a cache to determine if the at least one object 
is present in the cache; 

(b) determining the configuration for a selected persistent 
container; 

(c) allocating a transaction identifier to the at least one 
object; 

(d) allocating a resource corresponding to the transaction 
identifier to the at least one object; 

(e) checking the security of a client object that desires to 
access the at least one object in the persistent container; 

(f) checking the lock state of the at least one object in the 
persistent container; and 

(g) fluffing up the at least one object in the persistent 
container; 

(h) storing the fluffed up object in the cache; 

(i) returning the flu fled up object to the client object. 

52. The method of claim 51 wherein the step of fluffing up 
the at least one object includes the steps of: 

the extensible functions retrieving state data from the 
persistent container corresponding to the at least one 
object and creating the at least one object from the state 
data. 

53. A program product comprising: 

an object-oriented framework mechanism for providing 
persistence of at least one object in an object-oriented 
system by providing at least one persistent container, 
the framework mechanism including at least one core 
function defined by relationships between a plurality of 
classes within the framework mechanism, wherein the 
implementation of the at least one core function is 
defined by the framework mechanism and cannot be 
modified by a user of the framework mechanism, the 
framework mechanism further including at leasl one 
extensible function defined by at least one extensible 
class, wherein the implementation of the at least one 
extensible class is defined by the user of the framework 
mechanism by extending the at least one exteasible 
class, thereby defining a persistent storage environment 
that governs the operation of the framework 
mechanism, the framework mechanism comprising: 

a persistent container object corresponding to the at least 
one persistent storage environment and a first set of 
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object methods on the persistent container object to 
perform a plurality of predetermined functions to 
implement the persistent storage environment; at least 
one container configuration object that contains con- 
figuration data corresponding to at least one of a 5 
plurality of persistent containers and a second set of 
object methods to return the name of the persistent 
container and to identify at least one object that con- 
tains additional information regarding the persistent 
storage environment; 10 
at least one container class configuration object that 
contains configuration data for at least one class in at 
least one persistent container that defines which 
classes the at least one persistent container supports; 
at least one container store configuration object that 15 
contains configuration data that defines a container 
store that represents an extent of storage that a 
persistent container has configured to use; 
at least one resource object corresponding to at least 
one transactional resource in the persistent storage 20 
environment; 

at least one resource configuration object that contains 
configuration data for the at least one resource 
object; 

at least one resource manager object that contains a list 25 
of transactional resources that are available for use; 

at least one transaction manager object that manages a 
transaction by interacting with at least one object 
corresponding to a transactional resource; 

at least one lock manager object that provides control 30 
of concurrent accesses to at least one object in the 
persistent storage environment and a third set of 
object methods for locking and unlocking at least 
one object in the persistent storage environment; 

at least one cache manager object that manages at least 35 
one object in a cache and a fourth set of object 
methods for retrieving, storing, and deleting the at 
least one object in the cache; 

at least one security manager object that checks for 
proper authorization to access at least one object in 40 
the persistent storage environment; 
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at least one connection manager object that allocates at 

least one connection for a transaction; 
at least one access mode object that interacts with the 
at least one lock manager object to determine how at 
least one object in the persistent storage environment 
may be accessed; 
at least one lock object that determines whether at least 
one object in the persistent storage environment is in 
a locked state; 
at least one connection object corresponding to a con- 
nection that may be allocated by the connection 
manager object to a transaction; 
at least one distributed thread context object that pro- 
vides a context for at least one distributed thread 
used in the persistent storage environment; 
at least one handle object containing an identifier that 
uniquely identifies each object in the persistent stor- 
age environment; 
at least one class configuration object that contains a 
fully qualified class name corresponding to an object 
identifier in the persistent storage environment and a 
fifth set of object methods for determining the class 
name from the object identifier and for determining 
the object identifier from the class name; 
at least one cached entity instance object containing an 
in-memory representation of at least one object in the 
persistent storage environment; 
wherein the object-oriented framework mechanism 
defines a persistent storage system according to 
extended portions of the framework mechanism that are 
customized to provide a desired persistent storage 
environment; and 
(B) signal bearing media bearing the object-oriented 
framework mechanism. 

54. The program product of claim 53 wherein the signal 
bearing media comprises recordable media. 

55. The program product of claim 53 wherein the signal 
bearing media comprises transmission media. 

* * * * * 
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